According to the official documentation [1], the 13" M1 MacBook Pro also has this limitation:
> If you're using a Mac with the M1 chip:
>
> On iMac, Mac mini, MacBook Air, and 13-inch MacBook Pro, you can connect one external display using either of the Thunderbolt / USB 4 ports.
To be fair, several of my work laptops had a similar sentence in their user handbook, but two monitors were possible if you connected the wires before booting the laptop.
Really strange limitation, as it never scaled with bandwidth - so 4k 90+Hz was doable, but 2x 1080p60hz wasn't.
Some intel laptops (Ivybridge chips definitely, sandy Bridge probably) had such warnings because officially the chip couldn't support running three displays due lacking enough clock generators. Given the almost-analog nature of HDMI and naive LVDS, this meant trouble.
Thing is, Display Port has much more different physical layer derived from PCIE, and so connecting two displays by DP and running internal screen with LVDS worked just fine.
Yep, though that's really more of a question of chip: the M1 only supports two displays, for the laptop that includes the internal one (the Mini only supports two displays, and one only 4K via HDMI).
Not op, but for me the lack of native Wayland support is a deal breaker. And running it through XWayland has various issues (focus is broken, issues with HighDPI screens, etc).
If Fleet supports Wayland natively I might give it a try, otherwise it's dead on arrival for me.
> Good luck getting multiple different sized monitors to work well out of the box (e.g. laptop + external) on Linux, sometimes even with tinkering you are left with subpar scaling on one
It sounds like you might still be using Xorg?
These are all solved problems in Wayland (that is, as long as the applications are native Wayland clients, and not running through XWayland) but some people are still reluctant or unable (see NVidia EGLStream debacle) to migrate yet.
> If I try to connect headphones they'll invariably stop working before long.
Are you using PulseAudio or PipeWire? I've recently switched to PipeWire and all my bluetooth related issues went away. The progress that PipeWire has made over the last few months is amazing. At least in my case, it went from almost unusable to my daily driver in the span of two or three releases.
I'm going to buy this just to support Valve for their continued support in making Linux desktop a viable gaming platform. Their reasons may not be entirely altruistic, but there's no doubt that they had a tremendous impact on the Linux gaming ecosystem.
And it's not just the Linux gamers that are benefiting from their work. They also seem to be doing good work on lower-level parts of the stack (e.g.: graphic drivers, Flatpak, etc) that are improving the Linux desktop in general.
I'm going to use it as a (mobile NUC with screen + battery) and use it for programming etc.. not going to buy it for gaming at all. Having an amd machine with 16Gb ram + nvme storage + linux - perfect setup for day to day coding!
And will buy it as a thank you to Valve for supporting us all these years. I think this will pay off for them in the long run.
The intention is to use it with a usb-c dock, which I already own. Will probably buy the steam dock depending on what it offers and if it overlaps with my needs. Or if it is just plain sexy compared to the boring old usb-c dock then I'd rather buy that. The intention is not to get work done on a 7" screen, but on an external display + keyboard/mouse.
If you’re going to leave it docked, why not use a desktop so you don’t have to worry about deteriorating the battery just leaving it plugged in all the time?
It supports usb type c docks, which my mic, keyboard, mouse already uses to switch between my main rig and a macbook. And I have a bluetooth mouse of that fails.
Obviously not going to try be productive with an onscreen keyboard and 7" screen - will use it with peripherals in those cases.
I code on the train using xvkbd on my pinephone. You get used to it. A good editor like vim helps a lot. You're spending most of the time thinking not typing.
Curious, why the insistence on mechanical for a portal keyboard?
Perhaps I’m atypical, but I type more relaxed, smoothly, and faster on non-mechanical than mechanical.
Point of comparison is 150-175 wpm on laptop keyboards as opposed to 120-145 on mechanical. I’ve owned many mechanical keyboards, including very high end ones, and remain mystified about their aura.
Same. I already have $1,100 saved for a gaming PC, but since that might only buy a GPU right now I’ll just jump into this and hopefully wait out the GPU crunch.
That's not really true because of the advancements in compute technology and energy efficiency since then. It'll definitely use a lot less energy than a GTX 760 at the very least.
For a 7" screen jumping down to 720P is just fine. It's market niche is clearly not to compete with even a GTX 1050, but to be a little less than that to manage most games reasonably well and even newer games with a a minimally playable performance anywhere you go. I'm looking at it as a Nintendo Switch with a massively larger available library that can play most games I already own and don't have to wait & hope for ports when it's already more powerful than a Switch, the most comparable portable device available.
I mean that you can just set the game to be 720p with very little noticeable difference. Also at either 720p or 800p many custom graphics options are just not going to make things look any better/worse on a screen that size & resolution.
And 30FPS is just fine, especially for an ultra portable, and when you can probably get more than that out of it with customized graphics options. When I played Witcher 3 years ago it was actually on a machine that barely kept it going at 30FPS w/ low-medium settings. It was fine. One of the best games I played, and the lack of high quality textures too nothing away from that. Do you think people don't know they're making a quality trade off when they play the Witcher 3 on a Switch? Of course they know! NOW they'll be able to play it on a more powerful device that can serve as a full PC and has access to an enormous library.
You're complaining that this isn't good enough to be a primary gaming PC, and that misses the point: That's not the market target. This is setup to be a secondary device for existing gamers and an entry to PC gaming for others that want a wider selection than on a console or a Switch.
>Same. I already have $1,100 saved for a gaming PC, but since that might only buy a GPU right now I’ll just jump into this and hopefully wait out the GPU crunch.
Ah, yeah. $1100 will still buy you a significantly better gaming rig, and even better if you're willing to assemble it yourself.
I guess if you're holding out though, maybe the Deck will scratch the "buy new gaming shiny object" itch, and play games reasonable well at it's native resolutions, but if you have $1100 and it's not getting you what you want in a gaming rig, the Deck doesn't fill the gap.
Also I'm not confident that GPU cards will became easier and cheaper to find for a while. Someone that is related to the general chip industry told me 1.5 years. Until then constrained supply will probably make demand even more frantic.
Heck, just on cars alone: I just traded in a car for 2x the value it was listed at about 6 months ago. It was 12 years old and I knew I'd need a new car sometime in the next 1-3 years, and a new car today has massively more safety features (I have kids to worry about that for too) so I wasn't going to hold out and hope the used market went even higher.
And if car manufacturers whose electronics don't need the latest fab methods have these bottlenecks, I don't see the high end chip market getting much better, especially with Apple & Samsung eating any capacity TSMC can provide.
Apparently they are working with anti-cheat makers to get those games working on Linux before release? This honestly seems like the best news for Linux gaming... ever.
In this video focused on developers (https://youtube.com/watch?v=5Q_C5KVJbUw at 5:54) they mention they are working with BattlEye and EAC to get it working prior to Steam Deck release.
In my experience EAC was the reason that many games that were otherwise perfectly fine became broken because of anti cheat. This should make a huge difference.
Similar: I have a Hades Canyon GH Nuc because I want a very low profile rig that can run older games on high and new games on low and throw it in a bag w/ power adapter & go. Not only does this accomplish the same thing, it runs Linux and means that if I'm just bringing something along for gaming it's completely self contained.
Sure: The Hades Canyon gets (for my benchmarks) something a little bit under a GTX 1060.
The fact that the Zen 2 is 7nm vs the Canyon's 14nm means the performance/watt will be much better. It also has significantly more RAM, and better quality: LPDDR5 instead of DDR4. This also lowers power requirements while at the same time that it improves performance.
But no, I don't think this will be as powerful as a Hades Canyon. Although it also won't have to push pixels to a 2k display like my Canyon does. It doesn't need to be nearly as powerful to provide a similar experience on a small display. (in terms of smoothness. Also higher quality gfx setting will be wasted on this display size, so there's no point worrying about it not running well on "high" textures when the difference between "medium" won't be noticeable on 720p @ 7")
Oh I agree. I meant moreso that it would be awesome to see a zen4 + rdna3 option one day, if we don’t get zen canceled. If the performance increase from zen 2 to zen 3 could be repeated for zen 4… what a powerful little gamepad that would be!
> A systemd solution would need a VM running Linux w/ systemd even on Linux, in some cases.
But that's exactly what happens with docker anyway (e.g.: Docker is still running in the Linux VM when running it from a different operating system). And considering the widespread systemd adoption throughout the Linux ecosystem, it's far more likely for systemd to be already installed in the VM than docker anyway.
Systemd docker-replacement on a non-systemd Linux would need to run in a VM, though.
Systemd-docker-replacement: works only on systemd-Linux. Tooling for any other arrangement, including non-systemd linux, left as an exercise to the user.
Docker: works on Linux—systemd or otherwise. Has tooling to making working on macOS or Windows non-terrible and lets you use (mostly) the same commands as you would on Linux.
I'm saying that cross-platform tooling is what makes Docker Docker. Systemd can't replace it without replacing the tooling, even if it can do the same thing only on systemd-Linux.
> Systemd docker-replacement on a non-systemd Linux would need to run in a VM, though.
Would it? There's no reason this hypothetical systemd-docker-replacement couldn't be architected in a way that would not have a runtime dependency on systemd-the-init-system.
In any case, I'm not even sure if systemd wants to be a docker replacement (although it does seem to pick up more and more container features lately). But there's definitely some overlap between the two projects (in particular around process/service management) but podman is a much more direct competitor to docker than systemd.
I've been using it for a couple of months now (by patching the applications which haven't upgraded to Electron 12 yet) and it's been working great for me.
Is there anything in particular that is broken and/or missing from Electron's Wayland implementation? Or are you referring to GNOME's refusal to implement server-side decorations [1][2] as a limitation of Electron?
I don't think GNOME adding SSD would really help, considering a lot of Electron apps tend to use CSD to integrate with the target platform [0] [1] [2] [3]. Likely those apps should be fixed to correctly use CSD when applicable on all platforms, including GNOME.
My impression is that there will always be apps that don't care enough about decorations and would just prefer to use the operating system defaults and SSD provided a reasonable way to do that. But then there are also applications that do care enough about it, in which case CSD is way to go.
Usually implementing CSD properly for each platform requires a bit more work than just relying on the toolkit's default or on SSD. This shouldn't be a problem for applications that have the resources to do this properly, as in your examples. But I'm a bit afraid that, given Linux desktop's market share, smaller app developers might not have the resources to do this right and then Linux will start inheriting the look and feel from Windows and macOS. Maybe this won't be a problem in practice, but if this starts happening, then the experience for Linux desktop users will be worse than just using SSD.
In any case, we'll have to wait and see how it all plays out. I think both SSD and CSD have their use-cases and I still wish GNOME's would reconsider their position on this.
For apps that don't care about decorations, the toolkit is supposed to handle it. Inside Electron would be the safest place to implement a fallback for applications that don't care about decorations. That way you can be sure it will work on any window manager that doesn't provide decorations, not just GNOME... I don't want to retread more of the discussion that was in the github issue, but one way to do it is to have Electron hook into GTK and draw the GTK decorations, like Firefox does.
GNOME is an open source project, asking them to reconsider a position doesn't make sense -- the default response to every feature request is "no" unless someone volunteers to implement it. And honestly I see very little chance that the current GNOME volunteers are going to implement server side decorations in Wayland unless someone outside the project steps up to do the work. Maybe Canonical would pay for it? It's a major change for something that no GTK/GNOME apps would even use, and it wouldn't really benefit those small applications... they would still have to draw their own decorations to handle any other window manager that doesn't implement decorations, such as Weston.
> GNOME is an open source project, asking them to reconsider a position doesn't make sense -- the default response to every feature request is "no" unless someone volunteers to implement it
I don't think GNOME would accept a pull-request adding SSD regardless of where it came from (I'd love to be proven wrong though). In fact, someone asked this exact question [0] and it got no reply. But after reading the whole thread a while ago my takeaway was that such a pull-request would not be accepted.
> [...] it will work on any window manager that doesn't provide decorations, not just GNOME.
GNOME is the only real desktop compositor that doesn't support SSD. The main reason no one is complaining about Weston not supporting server-side decorations is because there aren't many (any?) people running Weston on the desktop. Also, there's no technical reason why SSD couldn't be added to Weston too.
Again, as I've mentioned before I think both SSD and CSD have their use-cases. GNOME thinks otherwise and that's okay. But it doesn't seem to be (only) due to lack of resources.
The pull request probably wouldn't be accepted because it's a major change and no other Mutter contributors are interested in reviewing such a patch or dealing with the (far-reaching) effects of it. GNOME is just the nonprofit open source project and it doesn't really allocate resources or have resources to spare -- it's got to be a volunteer who works on this who has enough resources to do it in a way that doesn't mess it up for everyone else, maybe that's Canonical who can do it, I don't know. There is also the option of implementing it first in one of the forks (Elementary, Budgie, etc), testing it out for a while, and then submitting it later after it's known that it works and doesn't break everything. Getting upstream to accept a 10,000 line patch is not easy under any circumstances.
There are other window managers that don't support server side decorations, I don't know why people always single out GNOME. Weston is important too, it's not often used directly but it's used as a base for other implementations -- if your app is busted and has no decorations on the reference implementation it can hardly be called a working Wayland app. Server side decorations do have a use case but they're not equivalent to client side decorations. I used to think they were until I tried to implement them in a window manager, now I see server side decorations as mostly a broken concept unless it's in very specific circumstances. The toolkits and apps have to implement client side decorations if they want to ensure the correct behavior everywhere, it's unavoidable.
I can definitely see the point in choosing XML for the Wayland protocols for the reasons you've mentioned (e.g.: strictly typed information) because one of their purposes is to be able to easily generate bindings and libraries from them.
However, that still doesn't make them a good format for human consumption as in reading them as a reference. That was the main motivation for creating this website.
To clarify I think the site is great, is was simply commenting that the choice of XML was good exactly because it enables things like the site and binding generation.
I've been trying to learn more about Wayland recently but most of the protocol documentation is found in XML files which makes for a poor reading experience.
Therefore I created a website which extracts the data from these protocols and publishes it in a format that's (arguably) better suited for reading.
You should take a look at the Wayland book https://wayland-book.com/
Written by Drew who is the author of wlroots, a fairly popular Wayland compositor library.
