Markaos

Yes, but these internal connections can be done in a variety of ways - for example the most common way to connect laptop displays (which I would definitely classify as internal) is using embedded DisplayPort.

But Wayland isn't a thing on its own, there's no "Wayland server" or anything else equivalent to the X server. The compositors like Kwin or GNOME's Mutter are Wayland implementations fully responsible for handling the display output.

You can blame Wayland for the lack of universally supported global hotkeys or for issues with apps that need to know exactly where on the screen they are - these are issues with the protocol - but not for bugs in one compositor's implementation of display management.

OK but Wayland is not responsible for arranging monitors

OK, I use GNOME on Wayland on EndeavourOS and have no problems regularly running a script in my phone's internal storage root directory. Go file a bug report to your distro, or at least provide some details.

I can't speak for these specific laptops, but unlike x86, ARM generally doesn't have a way for an OS to discover the available hardware, and most ARM platforms historically didn't do anything to help. There is a standard for UEFI on ARM where the UEFI is supposed to tell the OS about the hardware, but as far as I know this is only a thing on ARM servers and these laptops might not support it.

Without any way of probing for hardware or getting the information from UEFI, Linux has to somehow be compiled with all the info about the hardware built-in. And the build will be model-specific (there's a way to pass a file describing the hardware to Linux from the bootloader which enables a single kernel to be used on multiple models and have just a small part of the bootloader be model-specific, but somebody still needs to make that file and the manufacturers clearly don't intend to do that).

Just FYI, this seems to depend on where you get the Pixel from - if bought directly from Google, it should be offline-unlockable out of the box. The carrier-sold Pixels are a different story because the carriers demanded it.

Of course check this is true for the specific model you're buying before you actually buy it, but for me the unlock was never greyed out on my 7a.

This is about USB

As the other person said, what you're doing is pretty much emulating the behavior of tiling window managers. Edit while writing: I'm leaving the rest here because you might find it useful, but I've just realized that there's a tiling extension for GNOME (the desktop environment used by Ubuntu): Tiling Shell. That's definitely going to be the most painless way for you to try out tiling. There's also bound to be something similar available for KDE.

~~I think you will get a much better result than with virtual screens by configuring one to your taste, assuming you're willing to spend a few hours learning all the ins and outs (it's absolutely OK if you're not willing to do that).~~

Here's links to a few of them, you should be able to install them in whatever distro you prefer:

Hyprland - a tiling WM focused on good out of the box experience and animations (but it's still very configurable). If you want to get your feet wet with standalone tiling WMs as fast and painlessly as possible, this is IMHO the way

Sway - a more keyboard-centric tiling WM that leaves out the fancy stuff (for example I don't think there's any way to do window shadows or animations for all the window manipulation) and focuses on just being fast and efficient if you learn its concepts. This is the only one I've ever used for longer periods of time.

SwayFX - "Sway, but with eye candy!" - I don't think I can write a better description - has some graphics effects like window blurring or shadows.

proprietary Google-only format

Keyhole Markup Language

KML became an international standard of the Open Geospatial Consortium in 2008.

(...)

The KML 2.2 specification was submitted to the Open Geospatial Consortium to assure its status as an open standard for all geobrowsers.

Pixel - varies by manufacturer

That was the Nexus line, Pixel phones are all made by Google. Although Pixel 5 series and older use Snapdragon SoCs, while 6 onwards use Google's custom Tensor based on Samsung's Exynos. The major downside is IMHO the awful modem efficiency - if I want to keep mobile network on so that I can receive calls, my 7a is limited to 2 days of battery life if I'm lucky (and that's with barely using the phone, just a few pictures).

Edit: and I forgot to mention that all Pixels have great third party ROM support, except if you want GrapheneOS, in which case you need to go for the recent ones that are still supported by Google.

They probably fixed all the bugs they considered essential, and the rest is just nice to have fixes that can be moved to the next cycle if necessary (and they still have a week to work on them before release, although they might be careful not to introduce severe bugs now).

The general idea with this approach is that it doesn't make sense to block a release on a few bugs worked on by only a subset of available developers and having the rest idle - the project can be finished faster by moving the remaining tasks over to the next release and accepting the bugs in the meantime.

Not familiar with the API, and I'm not entirely sure if it's not just a bug in Eternity (fork of Infinity), but lemmy.one doesn't have downvotes and I don't get the option to downvote anywhere.