Offline
Also, it looks like NXP has picked up their Cadence HDMI/DP bridge/PHY driver upstreaming effort again, which is a great news as it's one of the biggest things we carry in the downstream #librem5 tree!
https://lore.kernel.org/lkml/20260407-dcss-hdmi-upstreaming-v21-0-4681070ab82f@oss.nxp.com/T/
Linux 7.0 has now been tagged, coming with 19 commits upstreamed from the Librem 5 tree - two by NXP and the rest by yours truly on behalf of @purism. Three more are already queued for 7.1.
While the mainline kernel still can't drive the display without extra patches, it's very close now 
#linuxmobile #mobilelinux #linux #kernel #librem5 #mainline #linuxphone #linuxsmartphone #shotonlibrem5 #purism #nxp #imx8mq #cats #catsofmastodon
@okias Nice, I was looking for a GNOME equivalent of KDE Itinerary recently but did not stumble upon this.
Protip: GTK can do hardware video acceleration using V4L2 on e.g. #Librem5, but only if you let it.
Adding "--device=all" to overrides lets it be used in #Flatpak apps that don't specify it in their permissions already, such as #Tuba.
If you happen to maintain a distro that runs on the #Librem5, then please be aware that all the known issues resulting in the modem dropping out from the USB bus have been resolved *years ago* already. This shouldn't happen even with runtime power management enabled if configured properly.
If you still see that happening on your distro, feel free to hit me up on Matrix and we'll work together to have your distro set up well.
@valpackett > making sure wakeups don't turn the display on xD
That'll get us, like, 90% there usability-wise already 
AFAIR gnome-settings-daemon simply turns it on unconditionally on resume from system suspend.
NXP has published their 6.18-based kernel tree and while browsing it I have noticed that they apparently found a way to support custom horizontal strides with mxsfb (by using some undocumented leftover IP for EPDC panels that imx8mq doesn't support). This may be interesting as it potentially opens a way to use linear PE in #etnaviv with the #Librem5's internal screen, so the GPU could render directly to the scanout surface without having to resolve its tiled buffer to linear afterwards. #imx8mq
All my #WebKit merge requests have been merged. Now #WebKitGTK supports touch PointerEvent API, touch point coordinates are fractional, synthesized mouse events are unbroken and both WebKitGTK and WPE WebKit handle pointer capture and release according to the spec. This should considerably improve compatibility of #Epiphany (#GNOME Web) with touch interfaces.
There are still some more things to fix in there, maybe someone in #mobilelinux #linuxmobile community would like to give it a try?
@datenwolf Fun fact - you can write a protocol to offload graphics operations over Wayland too, and you'll instantly get about the same adoption of it as that part of X11 has today 
With things like QtQuick being basically a big scene-graph canvas to draw you won't get much further than that anyway.
@datenwolf @newbyte @mirabilos @jzb The truth is - these toolkits used to work the way you describe and they have been reworked since for good reasons, which is why we can now do or think about doing things like multi-GPU with GPU hot-(un)plug, split render/display nodes, modifiers, zero-copy, desktop effects (incl. accessibility ones) and lots of other stuff that software from 90s simply did not have to concern itself with.
@datenwolf @newbyte @mirabilos @jzb So now you're saying that to reap the benefits of "old-school graphics system" you need to constrain yourself to very specific bits of software from the past? How is that different to this theoretical non-composited Wayland setup, which could actually be maintainable if anyone cared? What happened to "give the benefits to all applications, without extra effort"? 
@datenwolf @newbyte @mirabilos @jzb Meanwhile in the real world even X11 clients allocate their wholly owned surfaces to be presented with DRI.
@datenwolf @newbyte @mirabilos @jzb Yes, we even had Xvideo. But you know that offloaded surfaces can be efficiently overlaid, underlaid, alpha-composited, transformed? And it works today with device-independent APIs 
@datenwolf @newbyte @mirabilos @jzb Pretty much all of them these days, as this is handled by dmabuf feedbacks and buffer modifiers, so it works even with split render/display pipelines or with multiple GPUs.
@datenwolf @newbyte @mirabilos @jzb That's just one implementation, at least KWin and Mutter have their own ones: https://gitlab.freedesktop.org/emersion/libliftoff
GTK has GtkGraphicsOffload which is used by several apps out there - and that's just from the top of my head.
@datenwolf @newbyte @mirabilos @jzb Well, these things Just Work
in several commonly used Wayland compositors and toolkits out there today.
@datenwolf @newbyte @mirabilos @jzb > (and lets face it, that's the only configuration in which you're hitting the display engine)
Far from it! I have some hardware next to me that won't be able to smoothly output 4K video if it goes through the GPU (and not even speaking about CPU), and yet can do it. Display pipelines in modern SoCs are a bit more complex than in 1990s.
@datenwolf @newbyte @mirabilos @jzb Modern display engines provide some in-hardware composition abilities. You're explicitly not interested in window composition, fine, but applications want to draw over buffers that are opaque to them, such as video content, which can then go straight from the VPU to the display engine without CPU or GPU involvement.
That's well-supported today with Wayland and necessary for reasonable performance on some hardware out there.
@datenwolf @newbyte @mirabilos @jzb Well, maybe because the compressed buffer is produced by the GPU and the display engine knows how to decompress it on the fly while it's fully opaque to the CPU?
@datenwolf @newbyte @mirabilos @jzb So how are you going to offload surfaces to hardware planes while preserving the ability to save memory from unused portions of the window? How are you going to utilize display's engine framebuffer compression to hit bandwidth targets on high res screens?
X11 can do lots of things, but only once you make it move away from these "old-school" ways and explode the complexity.