02:21 silverpower: So I've been poking around the docs and looking for a solution to this, and there doesn't seem to be one - would it be possible to write a compositor/protocol extension that actually lets clients change the video mode of a designated head, honors modelines, stuff like that?
03:36 silverpower: I'll rephrase - is it possible (and not a total waste of time on my/others' part) to write a protocol extension (and corresponding compositor patch, and presumably at least one test patch for a targeted emulator or similar client) to allow clients to *properly* control a CRT monitor/television? That is, they're capable of performing modesetting as necessary to match the output of, say, an emulated system?
05:30 fluix: silverpower: are you looking for something like https://wayland.app/protocols/wlr-output-management-unstable-v1 perhaps?
05:36 silverpower: fluix: in theory. this looks very promising. there might not be enough granularity to make sure it gets exactly the right modeline from just width, height and refresh rate. you might also need to disambiguate by hsync
05:39 silverpower: normally the compositor shouldn't need to care about that, but you're trying to drive an analog system. honestly the more I've looked into it the more I understand why this has been left until now to do
05:40 silverpower: (it doesn't help that you can't even tell by CRTC which head would require more complex setup, since active converters exist.)
05:46 silverpower: anyway, thanks for pointing out wlr-output-management; ISTR it was only for giving settings apps permission to change display settings
05:46 fluix: np, mentioned it is all I really intended to do since I don't know much more :p
05:46 fluix: gl and someone else with more knowledge should be able to help
05:49 silverpower: *nods* I know it's a touchy subject about letting mere clients touch the modesetting knobs, but there are use cases beyond letting old games trash your desktop settings :V
07:43 kennylevinsen: silverpower: generally speaking, having clients manage outputs is a no-no. The privileged wlr protocol exists though, and sway specifically accepts modelines over its IPC (swaymsg).
07:44 emersion: silverpower: this protocol is for privileged clients. it should be unnecessary to use a protocol at all: most compositors let you set a custom modeline in the settings directly
07:48 silverpower: My understanding was that compositors actively ignored mode requests on the grounds of "surely everything is a 1080p+ LCD".
07:56 kennylevinsen: No, mode requests do not exist at all on the grounds of "modesetting is global state and causes glitches, clients do not get to do it"
07:57 kennylevinsen: Stuff that lets a client mess up user setup and other clients is generally a no-no
08:01 kennylevinsen: (and on CRTs, "malicious modesetting can make the display explode" as they'll try to obey their analogue input till death.)
08:10 daniels: silverpower: so what is the usecase?
08:11 silverpower: daniels: primarily emulators. Media players might want it too but they tend to not need the weirder modes that emulators ask for.
08:13 daniels: right, media players really just want to present at a certain interval, which is very different from letting them dictate modelines
08:15 silverpower: Two of the most common cases I'm thinking of are 240p/480i switching and PC emulation switching between 640x480 VGA and 720x400 text modes.
08:22 silverpower: The latter tends to also involve a refresh rate change. Sorry if I'm not being specific enough but I don't know the ins and outs of, say, Retroarch's Native CRT implementation.
08:22 wlb: wayland-protocols Merge request !53 closed (xdg-shell: Clarify when application-specific metadata should be available to compositors)
08:30 silverpower: Typically you use a set of direct or modified modelines per-system but on HDMI you typically use a set of 2560x(y) modelines that are not in the EDID but meet the minimum HDMI clock requirement.
08:31 silverpower: (this is for active converters on cards that no longer have VGA or DVI-I.)
08:35 silverpower: So far this hasn't been a real issue because the solution is obviously to use X11 and dump all the custom modes you need/want into xorg.conf.
08:38 silverpower: Which is still tenable in these last days of 2023, but that's not necessarily going to last
08:45 RAOF: You can still do that, but instead of dumping into xorg.conf you get to add them to the kernel command line.
08:47 silverpower: It'll go great with my very long multi-device rootfs stanza :V
08:49 RAOF: Well, from memory it won't be very long; all the _long_ bits will be in generating the modified EDID to add all the modes you want 😉
08:49 silverpower: Ah, you can generate a large EDID and it'll honor it?
08:50 RAOF: Yeah, you can override EDIDs on a pet-connector basis.
08:51 RAOF: s/pet/per/g
08:51 silverpower: Also it looks like with the super resolutions the client is already aware it needs to horizontally scale the output.
08:52 RAOF: I believe you want to go spelunking in "/sys/class/drm"
08:53 RAOF: Or maybe drm_kms_helper? Certainly _somewhere_ in sysfs.
08:57 silverpower: *nods* so the other half would be actually causing the mode switch to happen, preferably quickly since the display also needs to synch.
08:59 silverpower: That is, when the emulated machine's state requests a mode change, the emulator requests the suitable mode.
09:01 silverpower: That's the fraught part since just letting any app take the wheel on demanding a modeset causes many other problems.
09:02 RAOF: Welcome to the world of _compositor specific_!
09:03 silverpower: lol, figures. there's basically no chance of mutter supporting that, but I don't really expect them to.
09:04 RAOF: (For mirclient we let applications ask for a specific mode, and we might give it to them while they were full screen and focused)
09:06 silverpower: Yeah, that's another thing, how should it be handled when out of focus?
09:07 silverpower: Wait, that's compositor *and* emulator policy
09:09 silverpower: (in that the emulator typically decides whether to pause execution on focus loss)
09:16 silverpower: Regardless, I now have something more concrete to work with than I did yesterday.
09:21 silverpower: I was kinda afraid the long term answer was gonna be something along the lines of "use raw EGL to bypass the main compositor and a custom out-of-tree module to do unholy timing things"
09:22 wlb: weston Issue #858 opened by Marius Vlad (mvlad) Warn out users about starting Weston from a tty https://gitlab.freedesktop.org/wayland/weston/-/issues/858
09:28 kennylevinsen: silverpower: well, direct KMS but RetroArch has a backend for that already. Regardless, you do not need a module nor EDID modifications to do custom modelines with weird timings as long as the GPU accepts the mode.
09:30 RAOF: Yeah, if you're driving KMS yourself you can just throw modes at it directly.
09:30 kennylevinsen: The options are basically: 1. KMS where RetroArch alone controls the display, 2. custom display server that can do whatever you need whenever you need it, 3. Some new protocol that may or may not be adopted by mainstream Wayland servers
09:33 kchibisov: wasn't the solution for exclusive fullscreen to use viewporter?
09:33 kchibisov: The change modeline is called exclusive fullscreen.
09:33 kchibisov: when you map it to other windowing systems.
09:33 kennylevinsen: 1 and 2 are doable without any controversy. If you want to boot to RetroArch, 1 is enough. If you want to switch to other things than RetroArch as part of the same gaming session, 2 - a custom display server - is better
09:34 RAOF: My understanding is that custom refresh rate is a part of the requirements, which viewporter doesn't give you?
09:34 kchibisov: just draw at the rate you want?
09:35 kchibisov: And vrr could help with that.
09:35 kennylevinsen: I think they want to drive a CRT at the exact mode the game was meant for
09:36 silverpower: Yes, or the HDMI substitute mode
09:36 RAOF: Given this is for an emulator, they might be trying to race the beam, and that's not going to work unless the beam is actually moving at the right pace.
09:36 kchibisov: they have no control over refresh?
09:37 RAOF: Not with any current (standard) Wayland protocols, no?
09:37 kchibisov: why would you need a protocol for that?
09:37 kchibisov: use timer.
09:37 kennylevinsen: I don't think any CRTs or analogue outputs from GPUs support VRR
09:38 silverpower: Active converters don't either
09:39 silverpower: And CRTs really really don't like it when you refuse to stick to one pixel clock
09:39 RAOF: Well, if the things you're emulating use the fact that the cathode ray is scanning at a known rate in order to get effects that are otherwise impossible on the hardware, you kinda need the display to actually scan out at that rate.
09:39 silverpower: Yes.
09:39 kennylevinsen: But this might also be well into the area of needing a custom display server (or just direct KMS) because it is indeed a dedicated setup with custom hardware and highly specific restrictions
09:42 kennylevinsen: A regular desktop session on a 240i or 480i CRT would be painful anyway
09:42 silverpower: Right. You're expected on some level to understand the implications of using a CRT monitor or PVM/BVM.
09:44 silverpower: If you smoke a vintage 8513 because you didn't understand that it's not multisync, that's unfortunately on you
09:46 kennylevinsen: Then you could have a local protocol that resembles wp_viewport, but instead of scaling/cropping attaches a mode to a surface that it would use when the surface is fullscreen
09:46 kchibisov: kennylevinsen: so exclusive fullscreen which modesets?
09:46 kennylevinsen: Maybe with some configured safeguards for the monitor (max requestable res and refresh to keep the magic smoke on the inside)
09:47 kennylevinsen: kchibisov: yeah, in this special arcade Wayland server
09:47 kchibisov: probably could just use drm directly.
09:47 kennylevinsen: Then you can't change to other emulator apps easily though
09:48 kennylevinsen: RetroArch has a hidden-ish KMS mode; but based on what I read it might be slightly janky
09:48 kennylevinsen: That could be fixed though
09:49 silverpower: My particular use case is with a high-res 19" 4:3 monitor.
09:51 silverpower: But I doubt everyone who uses the current Native CRT support in RA or MAME is going to use it on a standard multisync computer monitor
09:54 silverpower: And part of why I asked all this is because figuring out the actual state of play for this has been nigh-impossible
09:56 silverpower: Admittedly in 2015 people still kinda believed that any day now LCDs would exist that solved all of these problems. We now know it's a lot harder than it looks to emulate CRT behavior.
10:07 silverpower: It looks like for high-res CRTs the answer might just be a new protocol but non-VGA CRTs will probably need direct KMS or a compositor built specifically for frontend duties.
10:17 soreau: silverpower: would it make sense to just go fullscreen+scale (and maybe have direct scanout) and just deliver frames based on the emulated frame timer?
10:17 silverpower: At what resolution? What refresh rate?
10:19 soreau: in this case, you wouldn't care about the real mode
10:20 soreau: the emulator isn't forced to render frames based on the frame event
10:21 silverpower: You're throwing away most of the advantages of this approach by using whatever resolution you set your CRT to for desktop use.
10:22 silverpower: One of the major ones is that square pixels is less common than you think
10:23 soreau: well you have the size of the monitor in mm, and the resolution, can't you do math with that?
10:23 silverpower: You'd have to fiddle with the controls every time the system or computer changed modes
10:24 silverpower: We'd be in the same boat as LCD users
10:27 silverpower: The entire reason you can correct your screen geometry to non-square pixels is because they aren't stretched by the output, but the monitor, and these modes are all distinct enough that a modern multisync will treat them differently
10:30 silverpower: But there's some things you can't fix by using your position and size controls and one of them is letterboxing. It's worse for the monitor to use the size controls to remove letterboxing because typically you have to max out vertical size.
10:31 silverpower: And high-res tubes aren't exactly made anymore
10:37 silverpower: There's probably some merit in at least considering using a subset of modes and taking more advantage of emulator-side interlacing, but if you want to switch between Mode X/Y, VGA and text modes on a PC emulator, *some* of those modes are going to need EDID timings that aren't in the monitor's list (because they're assumed), and half those modes (Mode X, text mode) aren't even square-pixel
10:37 silverpower: *deinterlacing
10:43 silverpower: Like there's a reason I popped in to figure out what Wayland's deal is with CRTs and how they could be better supported, and the answer is that the fixed-surface approach (which is forced by LCDs) comes with its own set of nasty hacks and nigh-intractable problems.
10:46 silverpower: At some point it starts to feel *less* silly to dig your old CRT monitor out of the closet or pick one up on a classifieds site.
10:55 silverpower: soreau: does that answer your question? like I said last night, the more I learn about the specifics the more I understand why it's largely been left until now to figure out a solution that everybody can live with
12:54 wlb: weston Issue #859 opened by Swaroop Muralidharan (swaroop) Weston-issues https://gitlab.freedesktop.org/wayland/weston/-/issues/859
13:56 daniels: I think the best answer for this is to DRM output leasing, which does already exist
14:11 mrelantek: Hello, I've installed Weston in Debian with Xfce and I want to share the clipboard between X11 and Weston. I've tried wl-clipboard and I can manually copy/paste using it. But is there a way to automatically share the clipboard between X11 and Weston?