Wayland Protocols 1.34 Introduces Better Drag & Drop, Explicit DRM Sync Objects

[agd5f]

agd5f

Is linux-drm-syncobj something AMD could tap into to provide VSR, Radeon Super Resolution, to Wayland desktops? Possibly other features, too, but now that I have a better GPU to utilize it, not having Super Resolution is something I'm starting to notice on anything that isn't GPU bound; desktop use and gaming. It really helps with font rendering on Windows.

That's not a request or anything like that. Just a curiosity and why I'm curious.

Not really. The compositor would need to explicitly support it. E.g., when the compositor gets the frame from the game, rather than just passing the frame to the GPU for display, it would scale it or filter it and then send that to the GPU for display.

[skeevy420]

Not really. The compositor would need to explicitly support it. E.g., when the compositor gets the frame from the game, rather than just passing the frame to the GPU for display, it would scale it or filter it and then send that to the GPU for display.

I wasn't sure if it was something that could be done in a way that would be able to send a list of resolutions to games, system settings, etc instead of just the monitor's supported resolutions like we have now. I'm not really sure how or where WMs, DEs, games, etc figure out what resolutions are supported. Is there was a way for AMDGPU itself to just tell the system it supports 5120x2160 in addition to the 3440x1440 native (I'm just using my monitor and settings as reference values)?

Is that kind of scaling even able to be done by the driver or DRM in a way that just ignores Wayland, X11, Arcan, or whatever? Like how DeviceMapper can supersede (or would it be subsede?) features like compression and case sensitivity with file systems?

[ireri]

YES I know, so pathetic. With X everything magically gets support, and it is perfect. I wrote a hello world program, and by magic I suddenly could do drag and drop under X. X is so great, magic provides implementations in every application. So, great!
And there are no drawbacks to X, you get a much superior single DPI experience instead of the confusing multi DPI.... I want to run my screens in suboptimal resolutions!!!!!

"Oh no, someone talked s about MY Wayland, even if it's true, I better hurry and talk s about X."

[Brittle2]

at this point we would need a totally new distro which would include only a selection of best technologies invented so far:
- 16-bit bootloader with only legacy bios support (e.g. Strictly requires a20 gate for no apparent reason) and sound blaster drivers like in grub 2
- 32-bit kernel with pae but without pcie support (mca, vlb, and agp should be enough for everyone)
- runit init service with high performance bash scripts and service sequencing using 'sleep' (experimental users can also try out launchd)
- oss version 1 sound system with arts and esd support
- dillo browser with flash and java 1.4 applet support
- xfree86 with user mode gpu drivers running as root (mir before it became wayland compatible should be ok as well)
- core utils written in pure cpl or bcpl (algol and cobol also considered kosher!)
- supported file systems: Fat12, fat16, ntfs via ntfs-3g, swap, and reiserfs 4
- all code in the state of the art bazaar version control system
- all bugs in the proprietary launchpad service
- all binaries should run in a snap container
- only one supported de: Unity
- all data stored in ubuntu one cloud
- contributions require signing a cla
- the installer will test your gender and dietary habits. Only overweight heterosexual (virgin) males who hunt their own meat and eat it raw are allowed to install the distro

LMAO i'm dead

[ehansin]

This is pretty off-topic, but since is "Wayland native", I just installed COSMIC via the "cosmic-epoch" Fedora Copr, and all I can say is that I'm pretty darn excited. I'll save elaborations for a more appropriate thread, but this looks like could be just what I have been looking for. Maybe not exactly, room for styling and etc., but dang nice for a "pre-alpha!"

[spicfoo]

"Oh no, someone talked s about MY Wayland, even if it's true, I better hurry and talk s about X."

Wayland and X11 are open source protocols. They do not belong to anyone. It's entirely valid to compare them.

[loganj]

Only three more years and the Wayland protocol is old enough to have sex.
Maybe it will have catched up with the Windows 95 features at that point.

it already had sex...it just never satisfies the community

[agd5f]

I wasn't sure if it was something that could be done in a way that would be able to send a list of resolutions to games, system settings, etc instead of just the monitor's supported resolutions like we have now. I'm not really sure how or where WMs, DEs, games, etc figure out what resolutions are supported. Is there was a way for AMDGPU itself to just tell the system it supports 5120x2160 in addition to the 3440x1440 native (I'm just using my monitor and settings as reference values)?

I'm not quite sure what you are asking. DRM kernel drivers expose a common modesetting API which the compositor or X server talks to. It allows the to query the connected displays, set the display topology, use planes, etc. Applications render their frame and hand it to the compositor which either composites it with other windows into a common display buffer and passes that to the GPU or passes it directly to the GPU for display in the case of full screen applications. The app can render at any size it likes and then the compositor can do whatever it wants with the frame. E.g., the app could render at 4K and then the compositor could either use the GFX engine to scale the image down to 2K for display or it could use the 4K image directly and tell the GPU use use the scaler in the display hardware to downscale it to 2K, etc.

Is that kind of scaling even able to be done by the driver or DRM in a way that just ignores Wayland, X11, Arcan, or whatever? Like how DeviceMapper can supersede (or would it be subsede?) features like compression and case sensitivity with file systems?

You could do stuff like that in the kernel driver, but it makes more sense to do it in the compositor because it knows more about what's actually going on on the desktop. If the kernel driver were to do some special scaling or filtering, it doesn't know whether it's a game or a word processor, or what. It just gets a frame. You'd need some special API for the compositor to tell the driver when it was ok to apply these things and what to apply, and at that point, you might as well just do it in the compositor as you'd have a lot more flexibility.

[polarathene]

Is linux-drm-syncobj something AMD could tap into to provide VSR, Radeon Super Resolution, to Wayland desktops?

The compositor would need to explicitly support it. E.g., when the compositor gets the frame from the game, rather than just passing the frame to the GPU for display, it would scale it or filter it and then send that to the GPU for display.

Probably something that romangg COMO project would do well at? A single module that any compositor built off COMO can easily add to enable the functionality?

Or maybe I misunderstand and you'd get the same perks if wlroots at the lower level integrated it (I'm just not sure if that's the right place since it's not really a Wayland specific thing, but rather a compositor one).

Although I'm not sure how well that'd work for the super resolution feature when the app/game already uses it internally? I guess you'd want to opt-out from one implementation (compositor vs game).

[dragon321]

"Oh no, someone talked s about MY Wayland, even if it's true, I better hurry and talk s about X."

The thing is it's not true.