Post B6piZz1ivo231JQybQ by uecker@mastodon.social
(DIR) More posts by uecker@mastodon.social
(DIR) Post #B6piIFAYAxUXs96Uds by navi@social.vlhl.dev
1 likes, 0 repeats
i hate x11 (the protocol) so hard, like excuse me what the fuck: tmp_name = g_ascii_strdown (dev->name, -1); if (strstr (tmp_name, " pad")) input_source = GDK_SOURCE_TABLET_PAD; else if (strstr (tmp_name, "wacom") || strstr (tmp_name, "pen") || strstr (tmp_name, "stylus") || strstr (tmp_name, "eraser")) input_source = GDK_SOURCE_PEN; else if (!strstr (tmp_name, "mouse") && !strstr (tmp_name, "pointer") && !strstr (tmp_name, "qemu usb tablet") && !strstr (tmp_name, "spice vdagent tablet") && !strstr (tmp_name, "virtualbox usb tablet") && has_abs_axes (display, dev->classes, dev->num_classes)) input_source = GDK_SOURCE_TOUCHSCREEN; else if (strstr (tmp_name, "trackpoint") || strstr (tmp_name, "dualpoint stick")) input_source = GDK_SOURCE_TRACKPOINT; else input_source = GDK_SOURCE_MOUSE;what do you mean this is how you recognize the type of an input device?
(DIR) Post #B6piZxeI3Rh2kLSkRE by gemini0@labyrinth.zone
0 likes, 0 repeats
@navi for a while i was wondering why the push to wayland that kde was making was so hard, then i realized just how much x11 actually sucks and how badly it needed the wheel to be reinvented
(DIR) Post #B6piZxux3V1La1G3PM by uecker@mastodon.social
0 likes, 0 repeats
@gemini0 @navi Is this actually the problem of X11 protocol? It has extensions and the XInput extention has a class field. But I am not an expert on this part. But I do not see any reason one could not have a nice extension if the old one should be problematic. So no, I still do not agree that there was any reason for reinvention.
(DIR) Post #B6piZy5wOdoM86OpXM by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @gemini0 the defined Xi classes from XInput2 are lacking for this, and for device types there's only XiMasterPointer and XiSlavePointer (oof terminology) which don't differentiate between different kinds of pointers(also XInput2's event structures are all defined in a UB way, instead of doing an union or shared header struct, they copy-paste all the fields from the header into all event types, then do arbitrary casts)
(DIR) Post #B6piZyKpVHiksHMikC by uecker@mastodon.social
0 likes, 0 repeats
@navi @gemini0 Lol, wasn't xinput2 designed by the wayland guys?
(DIR) Post #B6piZyVoqQVlQMVUsC by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @gemini0 i have no ideabut wayland was designed mostly by xorg developers so it's more likely to be the other way around
(DIR) Post #B6piZyjI2LHq68oFs0 by uecker@mastodon.social
0 likes, 0 repeats
@navi @gemini0 No, I don't think so. I think Daniel Stone was involved in designing xinput2 and then later decided X was all crap and has to replaced by Wayland (which I think it a much poorer design).
(DIR) Post #B6piZysVU4ewYj7cEi by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @gemini0 my all my experience writing wayland and xcb clients, i disagree about the design, imo wayland is better designed
(DIR) Post #B6piZz1ivo231JQybQ by uecker@mastodon.social
0 likes, 0 repeats
@navi @gemini0 yep, daniel stone. https://www.x.org/releases/current/doc/inputproto/XI2proto.txtI very much like x11 with xcb. It seems very clean to me. Where do you see a specific problem?I never did anything fancy with input devices though, so maybe this part is bad. But I notice that xinput had different device types...
(DIR) Post #B6piZzAaOr7ZSna3Ps by navi@social.vlhl.dev
1 likes, 0 repeats
@uecker @gemini0 it's been years since i used xcb, so i can't remember specific pains i had, sorrybut the overall structure of wayland, clear extension/capability negotiationno methods to "query state", server sends it once and the client stores it if neededno assumption of a 2d global coordinate space which allows 3d/vr compositors to exist as a wholesimple and minimal wire protocol (like really¹)damage tracking being the default expectation so my laptop's battery doesn't cryit used to lack protocols that people needed, those are being (slooowwly) addressed, but whenever they are, the solution ends up being better than all other desktop apis (the benefit of hindsight i suppose)¹: https://gaultier.github.io/blog/wayland_from_scratch.html
(DIR) Post #B6pj3TpZTw4SxGob5c by uecker@mastodon.social
0 likes, 0 repeats
@navi @gemini0 That overall does not look too much different to modern X and xcb to me.
(DIR) Post #B6pj3U1yjnznZkcVQe by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @gemini0 applications still expect a 2d global coordination system with self-positioningstill expect to be able to query or record any other window, or grab the keyboard at any time, and so onthose can't be ever changed without breaking clients
(DIR) Post #B6pj3UFRvilsFWvGQS by uecker@mastodon.social
0 likes, 0 repeats
@navi @gemini0 or so the wayland propaganda says. X had a security extension that isolated clients forever. It did not support some modern extensions. But I had patch to add those and the clients I tried worked just fine. I also do not quite see the issue with 2d global coordinate system. we had 3D desktops with X11 in 90s. maybe it was some hack, but I really can't see what the fundamental issue should be.
(DIR) Post #B6pj3USZ8xGMuD3js0 by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker i'm not sure about those extensions, since for ages i've seen people running separate nested x instances, one per client, just to isolate the clientsand the issue with 2d coordinates, is that vr compositors are not just 3d objects with 2d textures mapped onto them, each window is on it's own 3d coordinate, with custom rotations and such, possibly hand-moved by the user -- you can't do that and expect clients that position themselves in 2d to work properlyeven if you map regions of the 2d plane to specific 3d nodes, that breaks as soon as a window tries to move itself halfway into another window's space
(DIR) Post #B6pj3UeyOpBhWgreD2 by uecker@mastodon.social
0 likes, 0 repeats
@navi It is the XSECURITY extension also supported by ssh but usually deactivated. It isolates clients but also then sadly does not expose newer extension needed by modern clients. I still do not get the problem. So there are issues with older clients? Changing the protocol completely will also not make this work for older clients.
(DIR) Post #B6pj3UpFmbPY2ZfrEW by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker the problem is that you can't do it without breaking X11's api contractand it's not just old clients moving themselves, it's popup menus and anything that is position aware and has to share the coordinate spaceaka one big virtual display doesn't work for non desktop flatscreens traditional setupsand even for some nontraditional flatscreens it's a massive pain (e.g. a scrolling window manager with multiple outputs, where you'd need to either do hacky rendering tricks or deal with windows showing up across outputs when they shouldn't)
(DIR) Post #B6pj3UzXANdOYSU4G0 by uecker@mastodon.social
0 likes, 0 repeats
@navi but people did this with x11. wobbly windows, windows on a cube, 3d distorted windows? maybe I still missing your point.
(DIR) Post #B6pj3VCeNc7tD8cXhY by uecker@mastodon.social
0 likes, 0 repeats
@navi stuff like this: https://www.youtube.com/watch?v=4QokOwvPxrE
(DIR) Post #B6pj3VMZmi49hvGTAm by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker now i wonder what happens if any of those windows opens a popup while it's in 3d effect mode, that could be the issue, idk
(DIR) Post #B6pj3VWVBo0QChuOe0 by uecker@mastodon.social
0 likes, 0 repeats
@navi A popup is just another window, and the wm ultimately decides placement. And don't there is anything of this kind that can not be done on x11.
(DIR) Post #B6pj3VfidXNWfIDl0i by uecker@mastodon.social
0 likes, 0 repeats
@navi What I always found far more interesting is being able to move windows between devices. E.g. from a cell phone to the desktop, or from the desktop to some computer controlling a beamer, etc. This never was supported by GUIs but worked perfectly fine if you implemented it yourself.
(DIR) Post #B6pj3Vow5Gkd7sX7NQ by kirtai@tech.lgbt
0 likes, 0 repeats
@uecker @navi I remember that. It was supported in the protocol but not in xlib so most people didn't even realise it was possible.
(DIR) Post #B6pj3VzDT2yTdlLKOu by uecker@mastodon.social
0 likes, 0 repeats
@kirtai @navi Yes, it was originally part of the GPE palmtop environment. xlib had annoying limitations and also the default error handler was to terminate the program instead of trying to reconnect or something. But easy to do otherwise. I had high hopes for LInux 20 years ago...
(DIR) Post #B6pj3WAYms34CweO5A by kirtai@tech.lgbt
0 likes, 0 repeats
@uecker @navi The protocol was so much more powerful and expressive than the libraries.I too wish they'd done something better with it and Linux.
(DIR) Post #B6pj3WLY80q4l1nADA by uecker@mastodon.social
0 likes, 0 repeats
@kirtai @navi Well, there was XCB which is great, but just as I thought we will see progress, somehow the people paid to maintain the core infrastructure decided to redesign it. My conspiracy theory is that something like X was not controllable enough for the walled garden some people want to design for us.
(DIR) Post #B6pj3WXxNslPNVb4YC by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @kirtai "controllable"? out of everything to say, that's the most offthere's one, maybe two if you count the bsd fork, x11 serverswhile there's dozens of wayland compositors, many with their own protocol extensions for things unique to them, and a shared core for things that aren't unique
(DIR) Post #B6pj3WiakLGpuUZZ7w by uecker@mastodon.social
0 likes, 0 repeats
@navi @kirtai The question is, which one will you still be allowed to use on your systemd system that verifies your identity before you can use some app with remote attestation to watch some local content, and all this on a Rust-hardended system that can not be jail broken anymore.
(DIR) Post #B6pj3Ww3wG2uaGsK7k by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @kirtai and now you lost me, what does this has to do with that? either x11 or wayland would make no difference?
(DIR) Post #B6pj3X73HOpv8M16Fk by uecker@mastodon.social
0 likes, 0 repeats
@navi @kirtai You could lock down X as well, but in a world where proprietary pixels are not supposed to leave your device, something like X is completely the wrong design.
(DIR) Post #B6pj3X7lElP5AYLfMG by uecker@mastodon.social
0 likes, 0 repeats
@navi @kirtai The technology developed is shaped by the interests that fund their development. To some degree this is ok. But it explains the priorities. Network transpareny is not important, systemd needs to control everything, memory safety is really important, etc.
(DIR) Post #B6pj3XGGj8D1awKScS by navi@social.vlhl.dev
1 likes, 0 repeats
@uecker @kirtai `waypipe` and oh look at that the client has no idea i'm getting pixels out of the local device over the network
(DIR) Post #B6psqaBJYeUcQcTRiq by uecker@mastodon.social
0 likes, 0 repeats
@navi @kirtai btw: Just randomly found this:https://wayland.app/protocols/weston-content-protection
(DIR) Post #B6psqaLawQiSwVHekK by navi@social.vlhl.dev
0 likes, 0 repeats
@uecker @kirtai and basically nobody implements itbecause basically no one wants it
(DIR) Post #B6psqaVAMqN9QBlIfI by navi@social.vlhl.dev
1 likes, 0 repeats
@uecker @kirtai while also> This protocol is not intended for implementing Digital Rights Management on general (e.g. Desktop) systems, and would only be useful for closed systems. As the server is the one responsible for implementing the content-protection, the client can only trust the content-protection as much they can trust the server.yeah, i'm not worried much about thatthere is some merit in blocking out content from screenshots/recording (e.g. for a bank window or private chat, *extremely* useful for folks that make live streams) (also obviously not implemented like this)but the compositor has always the last say, and i'm not installing a compositor that forces drm onto me, the same way i wouldn't install a x compositor that does the same