ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
lsd|2 has joined #wayland
Leopold_ has joined #wayland
silverpower has joined #wayland
riteo has quit [Remote host closed the connection]
riteo has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
peeterm has quit [Ping timeout: 480 seconds]
riteo has quit [Remote host closed the connection]
riteo has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest12044
Guest11967 has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
<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?
Brainium has quit [Quit: Konversation terminated!]
i509vcb has joined #wayland
Guest12044 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest12049
Guest12049 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest12050
<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?
<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
<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
<silverpower>
(it doesn't help that you can't even tell by CRTC which head would require more complex setup, since active converters exist.)
<silverpower>
anyway, thanks for pointing out wlr-output-management; ISTR it was only for giving settings apps permission to change display settings
<fluix>
np, mentioned it is all I really intended to do since I don't know much more :p
<fluix>
gl and someone else with more knowledge should be able to help
<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
AnuthaDev has joined #wayland
Leopold_ has quit [Remote host closed the connection]
kts has joined #wayland
kts_ has joined #wayland
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
glennk has joined #wayland
<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).
<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
<silverpower>
My understanding was that compositors actively ignored mode requests on the grounds of "surely everything is a 1080p+ LCD".
sima has joined #wayland
<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"
<kennylevinsen>
Stuff that lets a client mess up user setup and other clients is generally a no-no
<kennylevinsen>
(and on CRTs, "malicious modesetting can make the display explode" as they'll try to obey their analogue input till death.)
kts has joined #wayland
<daniels>
silverpower: so what is the usecase?
<silverpower>
daniels: primarily emulators. Media players might want it too but they tend to not need the weirder modes that emulators ask for.
<daniels>
right, media players really just want to present at a certain interval, which is very different from letting them dictate modelines
<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.
mvlad has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
<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.
<wlb>
wayland-protocols Merge request !53 closed (xdg-shell: Clarify when application-specific metadata should be available to compositors)
<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.
<silverpower>
(this is for active converters on cards that no longer have VGA or DVI-I.)
rv1sr has joined #wayland
<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.
<silverpower>
Which is still tenable in these last days of 2023, but that's not necessarily going to last
kts has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
<RAOF>
You can still do that, but instead of dumping into xorg.conf you get to add them to the kernel command line.
<silverpower>
It'll go great with my very long multi-device rootfs stanza :V
<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 😉
<silverpower>
Ah, you can generate a large EDID and it'll honor it?
<RAOF>
Yeah, you can override EDIDs on a pet-connector basis.
<RAOF>
s/pet/per/g
<silverpower>
Also it looks like with the super resolutions the client is already aware it needs to horizontally scale the output.
<RAOF>
I believe you want to go spelunking in "/sys/class/drm"
<RAOF>
Or maybe drm_kms_helper? Certainly _somewhere_ in sysfs.
<silverpower>
*nods* so the other half would be actually causing the mode switch to happen, preferably quickly since the display also needs to synch.
<silverpower>
That is, when the emulated machine's state requests a mode change, the emulator requests the suitable mode.
<silverpower>
That's the fraught part since just letting any app take the wheel on demanding a modeset causes many other problems.
<RAOF>
Welcome to the world of _compositor specific_!
fmuellner has joined #wayland
<silverpower>
lol, figures. there's basically no chance of mutter supporting that, but I don't really expect them to.
<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)
<silverpower>
Yeah, that's another thing, how should it be handled when out of focus?
<silverpower>
Wait, that's compositor *and* emulator policy
<silverpower>
(in that the emulator typically decides whether to pause execution on focus loss)
<silverpower>
Regardless, I now have something more concrete to work with than I did yesterday.
<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"
<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.
<RAOF>
Yeah, if you're driving KMS yourself you can just throw modes at it directly.
<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
<kchibisov>
wasn't the solution for exclusive fullscreen to use viewporter?
<kchibisov>
The change modeline is called exclusive fullscreen.
<kchibisov>
when you map it to other windowing systems.
<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
<RAOF>
My understanding is that custom refresh rate is a part of the requirements, which viewporter doesn't give you?
<kchibisov>
just draw at the rate you want?
<kchibisov>
And vrr could help with that.
<kennylevinsen>
I think they want to drive a CRT at the exact mode the game was meant for
<silverpower>
Yes, or the HDMI substitute mode
<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.
<kchibisov>
they have no control over refresh?
<RAOF>
Not with any current (standard) Wayland protocols, no?
<kchibisov>
why would you need a protocol for that?
<kchibisov>
use timer.
<kennylevinsen>
I don't think any CRTs or analogue outputs from GPUs support VRR
<silverpower>
Active converters don't either
<silverpower>
And CRTs really really don't like it when you refuse to stick to one pixel clock
<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.
<silverpower>
Yes.
<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
Leopold_ has joined #wayland
<kennylevinsen>
A regular desktop session on a 240i or 480i CRT would be painful anyway
<silverpower>
Right. You're expected on some level to understand the implications of using a CRT monitor or PVM/BVM.
<silverpower>
If you smoke a vintage 8513 because you didn't understand that it's not multisync, that's unfortunately on you
<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
<kchibisov>
kennylevinsen: so exclusive fullscreen which modesets?
<kennylevinsen>
Maybe with some configured safeguards for the monitor (max requestable res and refresh to keep the magic smoke on the inside)
<kennylevinsen>
kchibisov: yeah, in this special arcade Wayland server
<kchibisov>
probably could just use drm directly.
<kennylevinsen>
Then you can't change to other emulator apps easily though
<kennylevinsen>
RetroArch has a hidden-ish KMS mode; but based on what I read it might be slightly janky
<kennylevinsen>
That could be fixed though
<silverpower>
My particular use case is with a high-res 19" 4:3 monitor.
<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
<silverpower>
And part of why I asked all this is because figuring out the actual state of play for this has been nigh-impossible
zipper has joined #wayland
mokee has joined #wayland
<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.
rv1sr has quit []
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
<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.
<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?
<silverpower>
At what resolution? What refresh rate?
<soreau>
in this case, you wouldn't care about the real mode
<soreau>
the emulator isn't forced to render frames based on the frame event
mokee has quit [Quit: off]
<silverpower>
You're throwing away most of the advantages of this approach by using whatever resolution you set your CRT to for desktop use.
<silverpower>
One of the major ones is that square pixels is less common than you think
zipper has quit [Ping timeout: 480 seconds]
<soreau>
well you have the size of the monitor in mm, and the resolution, can't you do math with that?
<silverpower>
You'd have to fiddle with the controls every time the system or computer changed modes
<silverpower>
We'd be in the same boat as LCD users
<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
<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.
<silverpower>
And high-res tubes aren't exactly made anymore
kts has quit [Ping timeout: 480 seconds]
<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
<silverpower>
*deinterlacing
<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.
<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.
junaid has joined #wayland
<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
privacy has joined #wayland
narodnik has quit [Quit: WeeChat 4.1.2]
narodnik has joined #wayland
glennk has joined #wayland
gallo has quit [Quit: Lost terminal]
Moprius has joined #wayland
gallo has joined #wayland
Moprius has quit [Quit: bye]
kts has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
jess has joined #wayland
JakeSays has quit [Remote host closed the connection]
JakeSays has joined #wayland
junaid has joined #wayland
garnacho has joined #wayland
junaid has quit [Remote host closed the connection]
<daniels>
I think the best answer for this is to DRM output leasing, which does already exist
mrelantek has joined #wayland
<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?
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
glennk has joined #wayland
Company has joined #wayland
kts has joined #wayland
mclasen has quit []
mclasen has joined #wayland
rv1sr has joined #wayland
rv1sr has quit []
rv1sr has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
junaid has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
junaid has quit [Remote host closed the connection]
systwi has quit [Ping timeout: 480 seconds]
Guest12050 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest12104
systwi has joined #wayland
andreasbackx has joined #wayland
privacy has quit [Quit: Leaving]
AnuthaDev has quit [Ping timeout: 480 seconds]
andreasbackx has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
alarumbe has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #wayland
glennk has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
AnuthaDev has quit [Read error: Connection reset by peer]
powyum has joined #wayland
AnuthaDev has joined #wayland
kts has joined #wayland
kts has quit [Remote host closed the connection]
powyum has quit []
AnuthaDev has quit [Read error: Connection reset by peer]
systwi has joined #wayland
AnuthaDev_ has joined #wayland
kts has joined #wayland
kts has quit []
systwi has quit [Ping timeout: 480 seconds]
AnuthaDev_ has quit []
i509vcb has joined #wayland
systwi has joined #wayland
rasterman has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]