Further thoughts on Xorg "vs" Wayland etc -- was: Re: Release v1.4?

[bokr@bokr.com]

[-- Attachment #1: Type: text/plain, Size: 6274 bytes --]

Hi brian, et al,

On +2022-06-17 11:37:18 -0400, Brian Cully via Development of GNU Guix and the GNU System distribution. wrote:
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > So plain ‘emacs’ package doesn’t work on Wayland?  That sounds like a
> > recipe for a poor user experience, no?
> 
> The mainline Emacs is not Wayland-native, but it (along with just about
> everything else) will run fine under XWayland. It's how I've been running it
> for some time now. The user experience is almost indistinguishable from
> either the ‘pgtk’ branch or the mainline, X-only branch.
>

Yes, and NB:  Xwayland does not shut out native wayland.

It may even share more nicely than that, depending on system.
On my old Puri.sm Librem13v4 PureOS/amber-variant-of-debian system...
-----------cut here---------------start------------->8---
# $ uname -rv
4.19.0-19-amd64 #1 SMP Debian 4.19.232-1 (2022-03-07)
-----------cut here---------------end--------------->8---
...I can switch back and forth between Xwayland that does
all the stuff that needs X or Xorg (gnome and browsers, and Audacity
and all that) and my hacky experiments with bypassing X and
talking to the compositor in C.

The compositor happily places my pixel buffers on the screen together with
firefox or texworks or whatever else is running, so there is not necessarily
a Wayland "vs" Xorg conflict. YMMV I would guess, but works for me :)

This seems to me like it demonstrates an opportunity to encourage developers
to get their feet wet with X-server-indepedent apps. (That doesn't mean
giving up all the graphics and font software that paints pixels into buffers --
it "just" factors out the buffer compositing)

My system also permits switching to a framebuffer ( /dev/fb0 ) tty3 based
environemt, while leaving the gnome gui stuff running.
Ctl-Alt-F3 gets me a console login prompt. Ctl-Alt-F2 switches me back,
whether I logged out of the console shell or not.

If you are a member of the video group, you can read and write the
frame buffer as a 1920x1080x4 byte mmap whose address you can get
with an ioctl. Other geometries are of course possble. 

I wrote some C to poke character cells from the kernel sun12x22 font.
Long time ago. I have been meaning to port my pixelpoking to wayland,
and have wip stuff, which I will share at some point :)

The reason I was in frame buffer mode today was the gnome side got
total locked, so I thought I could Ctl-Alt-F3 and kill off stuck bits.
Which I did -- killed the whole GUI side, in the end. An alernative
to rescue/maintenace mode, before going there, IOW.

But since I was there in console fb mode, I wanted to check that
my old font demo worked. It did :)

BUT: Fn Prt Sc had no hook like in gnome, so I wanted to save the
display. Guess what you can do?

To make a screenshot:
    xz -kzc /dev/fb0 > some_xzss_name.xz
To display such a screen-shot:
    xz -dc some_xzss_name.xz > /dev/fb0

This works fast, and the compression is better than the .png files from
gnome's screenshots. Of course this doess not coordinate with anything else
that may be painting the screen, so it will get mixed with updates in sometimes
curious ways, since the compositor avoids update screen areas it thinks haven't
changed. If you poke pixels there, they'll stay until the compositor gets someting
new for that area,

I'll try to attach one I made. It shows all the kernel sun12x22.c characters
with bounding boxes in red and hex index numbers at the array edges.

Maybe this dual fb0 and Xwayland capabilty could help someone?
You get it all "for free" with some systems, and it doesn't demand anything.

There is tricky stuff going on though. So no warranties
from me on any of this info :)


> > (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> > tiling window managers probably can’t switch.)
>

I don't know how much work, but I would guess they can be made
to work alongside wayland, if not using wayland to best advanage.

Best would be to wean emacs of X, IWT.

Otherwise they can probably play nicely on the same back end,
not sharing screen space maybe, but flipping between with some key hit.

A quick check on if you have drm-driven displays:

-----------cut here---------------start------------->8---
# $ head /sys/class/drm/*/status
==> /sys/class/drm/card0-DP-1/status <==
disconnected

==> /sys/class/drm/card0-eDP-1/status <==
connected

==> /sys/class/drm/card0-HDMI-A-1/status <==
disconnected
-----------cut here---------------end--------------->8---

BTW, if you want to hack native wayland, I recommend [0]
to start with. The examples mostly worked for me.

but so much is developing so fast that things
like using anonymous files and mmap-ing them to pass
to wayland as private buffers may show up only
while your're looking for something else on stackoverflow
or wikipedia or reddit or ... you may miss it.

[0] https://wayland-book.com/introduction.html

Sorry to interpose so much, the context for "this" (I think) was:

--8<---------------cut here---------------start------------->8---
> > (FWIW folks like me who use exwm, ratpoison, or one of these geeky
> > tiling window managers probably can’t switch.)
--8<---------------cut here---------------end--------------->8---

Well, I think some may be able to switch, or coexist. But I've been wrong before :)

> This is correct, but I don't see why this should prevent Guix offering the
> option for Wayland-based compositors/window-managers out of the box as all
> it does is offer more options for users.
> 
> > I have no objection to defaulting to Wayland, but my gut feeling is that
> > we have enough on our plate for 1.4 already, so I’d rather delay that
> > post-release.
> 
> Unless I'm misunderstanding something, I don't believe that setting the
> ‘wayland’ flag to #t in gdm-configuration causes Wayland to be used for your
> desktop environment, it merely *allows* it to be selected from the greeter.
> When logging in you can select from Gnome under X, Gnome under Wayland, or
> other window managers you may have installed under either environment.
> Without that flag only the X11 window managers will be selectable.
>

I think you must be right, Brian, or we should
"Make it So," as the Captain said.

> -bjc
>
--
Regards,
Bengt Richter

[-- Attachment #2: xzss20220618_210042.xz --]
[-- Type: application/x-xz, Size: 15020 bytes --]