ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
ity1 has joined #wayland
ity has quit [Ping timeout: 480 seconds]
eponym has joined #wayland
navi has quit [Quit: WeeChat 4.1.2]
zxrom has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
guru__ has joined #wayland
rasterman has joined #wayland
fmuellner has quit [Read error: Connection reset by peer]
eponym has quit []
guru_ has quit [Ping timeout: 480 seconds]
eponym has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Guest91 has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
kts has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Tramtrist has joined #wayland
CME_ has quit [Ping timeout: 480 seconds]
<Tramtrist>
hello all.. Is there a way to make a wayland program run 'always on top' ? The program in question is not presenting an app_id in swaywm and Im wondering how to bring it to the front
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
<soreau>
are you not able to see it? I thought sway was a tiling manager with optional floating views
<soreau>
but really, this is more a question for #sway on liberachat
<Tramtrist>
This particular program doesnt seem to be showing a 'window' at all
privacy has quit [Remote host closed the connection]
privacy has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
systwi has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
zezba9000 has joined #wayland
<zezba9000>
Hi, I'm trying to solve an issue thats really confusing me. wl_subsurface_set_position doesn't seem to do anything to offset my sub-surface
<zezba9000>
The sub-surface is set as wl_subsurface_set_desync and displays in the the top-left corner of the main surface
<zezba9000>
Not sure what I'm missing to get the offset from wl_subsurface_set_position to work
flom84 has quit [Remote host closed the connection]
<vyivel>
zezba9000: subsurface position is treated as a part of the parent surface state
<vyivel>
i.e. you must commit the parent surface after sending wl_subsurface.set_position
bindu has joined #wayland
<zezba9000>
Ok nevermind figured it out. Need to call wl_surface_commit on both surfaces after everything is done then call wl_display_flush. So my order of operations was wrong
kts has quit [Ping timeout: 480 seconds]
<zezba9000>
Is there a way to request a Wayland window is centered on the screen client size in code?
<vyivel>
no
<zezba9000>
@vyiel I mean at Window creation time. Say for like a splash screen. This must be possible
<zezba9000>
Not moving a Window but requesting its created centered for splashes or game-engine windows
<zezba9000>
I can just do with in X11 and centering windows works in XWayland. There must be a way to create a window centered in Wayland to match this behaviour
<zezba9000>
Other major thing I'm trying to find docs for is enabling server-side decorations on KDE and ignoring my own
flom84 has joined #wayland
flom84 has quit [Remote host closed the connection]
kts has joined #wayland
<vyivel>
for ssd, see xdg-decoration
<vyivel>
a window can't center itself on creation time either
diwoka has joined #wayland
diwoka has quit []
<zezba9000>
@vyivel A Window should be able to request it wants to present itself centered like all other operating systems can do. I'm not saying manually set the position. WinRT framework for example allows this request for Window creation without allowing you to get or set a Windows position.
<zezba9000>
Otherwise you can't do splash screens for an IDE like CLion, Rider, etc
<vyivel>
imho using xdg_toplevels for splash screens is a bad idea anyway
<vyivel>
i personally wouldn't want a window appear wherever it wants
<zezba9000>
You want a splash screen to appear in the top left of the screen? what??
<vyivel>
*i* don't want a splash screen to appear at all, if that's what you're asking
<zezba9000>
Also you want a Windowed game to show up in the top left? Like what again man. No one makes software like this.
kts_ has joined #wayland
kts_ has quit [Remote host closed the connection]
<vyivel>
where a window appears is a compositor's policy
<zezba9000>
No its NOT lol
<rolf>
That's how I interpreted it as well. Or at least it should be something the user has control over. (but... why even have 'splash' screens?)
<vyivel>
it can decide that a window must be centered
<zezba9000>
Just no
<vyivel>
it can also decide it should be tiled
<vyivel>
or maximized from the start
<vyivel>
or minimized
<vyivel>
or whatever else the user wants
<zezba9000>
If I open Rider I want its launcher that lets me select a project to show in the center of my screen BUT I don't want that for every app
<zezba9000>
All OSes agree with me here too
<zezba9000>
ALso I don't see anything related to get_toplevel_decoration in xdg-shell-client-protocol.h
<rolf>
I agree with vyivel here; it is up to the window manager to decide, not up to the program.
<emersion>
the way splash screens are going to work on wayland is by having the app tell the compositor "this is a splash screen", rather then "put this in the center"
<vyivel>
splash screens have very different semantics from regular windows
<zezba9000>
One size fits all is nonsense
<zezba9000>
Again this isn't about Splashscreens
<zezba9000>
Its about game windows, selection dialgs etc
<vyivel>
as i said, where those are placed is up to compositor
<zezba9000>
Splash screen is just one of many things. And its not up to you what a software needs to do
kts has quit [Ping timeout: 480 seconds]
<zezba9000>
Yes it is up to the compositor. So is it with WinRT frameworks BUT theirs are done correctly here
<zezba9000>
Its a request that doesn't have to be respected
<rolf>
Still... it is not up to the program to decide this. I would become incredibly annoying and an a bypass mechanism if software could decide the placement of windows. Next thing you'll know is we end up with "Windows" behaviour like focus stealing.
<emersion>
please, don't try to argue that another framework does something so we should do the same
<rolf>
( *It would )
<emersion>
this is not how it works
<zezba9000>
Wayland needs to support center Window request standards for game Windows at min (this is the field I'm in btw)
<zezba9000>
I'll agree how I see fit. Not looking at other approches is utter nonsense
<emersion>
your tone is really not helping here
<zezba9000>
Particularly ones that are doing the same thing as Wayland but actually expose things for important reasons
<zezba9000>
**agrue
<zezba9000>
My tone is one of frustration
<zezba9000>
I can center my game Window on Wayland if its using X11
<emersion>
we looked at other approaches and decided against them
<rolf>
"99% of OSses have a Start button, therefor we should have a Start button as well"
<zezba9000>
But I can't using Wayland direction? Like what lol
<emersion>
that's basically why wayland exists at all
<zezba9000>
God you're out of toucch here
<emersion>
wayland exists because X11 developers learnt from their mistakes
<zezba9000>
Whatever Linux can fall off a cliff here and people will stick to X11 on SteamDeck I guess
<zezba9000>
Anyway whatever I guess
<zezba9000>
No Wayland did not learn from X11 mistakes as they clearly didn't look at what others were doing and why
<zezba9000>
Thats actually learning is learning from others
<emersion>
X11 does the same as win32
<emersion>
anyways
<zezba9000>
You realize Windows and macOS have things they learned Wayland could learn from right
<emersion>
i don't think this conversation is going anywhere at this point
<zezba9000>
This echo chamber isn't good for anyone
<emersion>
let's stop here.
<zezba9000>
Sure
<zezba9000>
"X11 does the same as win32" FYI this is why I said WinRT. Very different
<zezba9000>
I highly recomend looking at WinRT windowing system here. Its pretty much wayland in its security at a client level but allows the hints I'm suggesting. Leaving it hear but want to make that clear. Its worth considering some of the ideas
anarsoul|2 has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
<rolf>
The user can decided how they would like windows to be placed by setting appropriate configuration for the window manager they use. Ie the user may choose to have splashscreens, dialog windows et cetera floating and centered but they can also choose to set specific window types to be tiled, always open on screen #1, always be topleft, et cetera. Personally I have set several window
<rolf>
classes to open either centered (floating) or at a specific location. The program can set the window class, the user decides how to display that windwo class.
<soreau>
wayfire entertains such wild times
<soreau>
it lets xwayland windows place themselves
DodoGTA has quit [Quit: DodoGTA]
<zezba9000>
The app dev should be able to provide Window hints the compositor can override by user choice. This is the correct ballance between app devs and the OS. It allows for both. App designers design apps to feel and function particular ways. A DE that is tile based might override expectations but at least the option exists for an OS to behave the way they have since the 80s.
<zezba9000>
Tiled Window managers are a fraction of a percent of users. Outside touchscreens these only have so much value and its just not how people think in many cases IMO
sima has joined #wayland
<zezba9000>
Am I wrong in saying Wayland will have a memory leak if a program craches?
<zezba9000>
I notice if my Wayland app crashes it will not open again unless I call "shm_unlink" on the shared memory buffers
<JEEB>
given that each wayland compositor more or less has their own server-side logic, you would probably be wrong in saying it as a general comment about wayland itself - unless that memory leak is written into the specification
<JEEB>
and if it is written into the specification, it is most likely a bug which would get fixed
<emersion>
zezba9000: that sounds like a client bug
<emersion>
if a client leaks a file, the compositor can't do anything about it
<emersion>
the right way to do ot is for the client to unlink the file right after opening it
<emersion>
it*
<zezba9000>
This is PopOS.
<zezba9000>
So same as Ubuntu and Fedora I'd think
<zezba9000>
"that sounds like a client bug": Of course. If my app crashes it shouldn't cause a memory leak in Wayland
<zezba9000>
But in PopOS it is
<JEEB>
depends on whether the buffer or file or whatever is on client side or server side, I guess?
<JEEB>
since emersion brought up it being a possibility that the client took a resource and in that case the server would be unrelated
<emersion>
zezba9000: this is client memory, left by the client
<emersion>
the compositor is not involved in the leak
<zezba9000>
Umm if an app crashes on Windows, macOS, ANdroid etc. It doesn't cause a mem leak in the compositor
<emersion>
there is no compositor mem leak here
<zezba9000>
It doesn't matter if its the clients fault. This would make the OS prone to memory issues
<JEEB>
yes, and I think while I took it at face value that you were actually talking about a compositor leak, emersion noted that what you mentioned is a leak on the *client*
<zezba9000>
So I can create a buffer without shm_open ?
<emersion>
you call shm_open, then right after call shm_unlink
<zezba9000>
Ok and if the app crashes before that?
<emersion>
see any Wayland client for reference code...
<emersion>
if the app crashes exactly between these two calls?
<zezba9000>
Isn't this just an easy attack vector at this point?
<emersion>
... attack vector?
<zezba9000>
Nevermind, if its not easy to see why I'm not going to have the conversation
<emersion>
the memory is accounted for the client
<emersion>
not the compositor
kts has joined #wayland
<JEEB>
I think the thing he might be talking about is someone requesting more and more buffers on purpose without releasing them, but that would only be an issue if those buffers would be in the memory space of the compositor. are they? if they are not, then it's just the client filling up its memory space and the compositor is fine?
<emersion>
no, it's client memory
<zezba9000>
It just feels like any buffer used on the client should always have a process assosiation. If I and debugging then hit stop and kill the app it doesn't clean up memory. I can't imagine this happening with X11, Win32, Cocoa apps etc? Am I wrong?
<zezba9000>
So if process died all memory shared or not gets released.
<zezba9000>
This is what happens with OpenGL, Vulkan apps for example
<emersion>
your client is doing the same as opening a file on /ymp and not cleaning it up
<emersion>
/tmp
<emersion>
as I said, the compositor is not even involved in this leak
<zezba9000>
Yes but why is Wayland using these buffer types without process association?
<emersion>
I would suggest that you read more information about buffer sharing
<emersion>
like wayland-book.com
valy_ has joined #wayland
<valy_>
directed here from kde-devel: I'm trying to fix one issue with Krusader on wayland, but I don't have that much experience with KDE Libs so -> if the viewer window is already open but minimized or behind the main krusader window it should come to foreground when I open a new tab
<valy_>
KWindowSystem::activateWindow(windowHandle()); makes the window blink in the task bar, but I found no refrence for bringing the window to the top
<orowith2os[m]>
(director being me) - the main problem is bringing a window to the foreground
<valy_>
yep
<orowith2os[m]>
I recall it being expected that apps can't force themselves to the foreground, but I think it was possible to do that outside of starting a new app
<orowith2os[m]>
or maybe I'm thinking of passing the focus from app to app, which does have a protocol of its own
<soreau>
this works in wayfire with focus-request plugin IIRC
<valy_>
I think this is the activation token protocol
<valy_>
does it make the problem easier if both windows are owned by the same application?
<soreau>
my use case is a text editor is open but it's behind a terminal where I run the text editor on a file, it doesn't open a new instance, it just brings the text editor on top and opens the file
<JEEB>
anyways, I would actually rather ask that question about shmem usage/freeing from the linux kernel or whatever is implementing shm_open/shm_unlink, rather than wayland. since unless the compositor somehow takes ownership of the shmem, it's still under management of the application. so in theory if your application dies while still being the single owner of that shmem object the manager of these things would
<JEEB>
be able to free it.
<orowith2os[m]>
valy_: ish, what's important is one window having focus, I think. still trying to find anything in the protocol :v
<soreau>
valy_: not if your compositor doesn't support this feature
junaid has joined #wayland
<zezba9000>
Anyway thanks for the info. Got to go to bed. I do think Wayland devs should consider the WinRT center window hint. Kind of annoying not having this for windowed games. I'll have to look more about shm. On Windows I feel like every shared memory buffer like this died with the process but would have to confirm.
tyzef has quit [Quit: WeeChat 3.8]
<orowith2os[m]>
aaaaa
<orowith2os[m]>
how the hell does GTK do it?
<JEEB>
it could be that posix and/or linux went the file way, and files don't automagically disappear :)
<soreau>
looks like in wayfire, it calls the focus_request plugin on map, which decides what should happen
<orowith2os[m]>
I looked at Wayfire's plugin, but there's not really anything interesting I can see
<soreau>
but for xwayland views, it's also called on request_activate
<orowith2os[m]>
where does wayfire get a FocusRequest event from?
<orowith2os[m]>
wlr-layer-shell?
<soreau>
oh I forgot to look at the in tree plugins..
privacy has quit [Quit: Leaving]
<soreau>
it's gtk-shell looks like
<soreau>
and xdg-activation
<soreau>
and foriegn-toplevel
<orowith2os[m]>
xdg-activation makes sense for passing focus between
<soreau>
all these protocols are implemented as plugins and call focus_request at some point
<orowith2os[m]>
apps
<orowith2os[m]>
gtk-shell seems the most interesting, as it actually just brings a window to focus
<soreau>
yes, this is really convenient
<orowith2os[m]>
valy_: there ya go, take a peek at gtk-shell
<valy_>
right, got it
zezba9000 has quit [Remote host closed the connection]
<orowith2os[m]>
though, doesn't look like kwin implements it....
<orowith2os[m]>
if the wayland.app menu is to be trusted
<orowith2os[m]>
aaAAAAAA
<orowith2os[m]>
then how does it do it on KDE???
<valy_>
KWindowSystem::activateWindow uses the activation token
<valy_>
which seems to be the KDE way of doing this
<orowith2os[m]>
my brain hurts
kts has quit [Read error: Connection reset by peer]
<orowith2os[m]>
I shall leave you to it
glennk has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
lsd|2 has joined #wayland
DodoGTA has joined #wayland
navi has joined #wayland
diwoka has joined #wayland
azerov has quit []
azerov has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
junaid has quit [Remote host closed the connection]
MrCooper has quit [Remote host closed the connection]
glennk has joined #wayland
MrCooper has joined #wayland
diwoka has quit [Remote host closed the connection]
aknot has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
tyzef has joined #wayland
kts has joined #wayland
nerdopolis has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
garnacho has joined #wayland
privacy has joined #wayland
ofourdan has quit [Quit: Lost terminal]
zxrom has joined #wayland
valy_ has quit [Quit: Page closed]
tyzef has quit [Quit: WeeChat 3.8]
privacy has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
Leopold_ has quit [Remote host closed the connection]
julio7359 has quit [Ping timeout: 480 seconds]
guacamolie has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<guacamolie>
hello, does anyone know of a small-ish Wayland compositor that I can study which _does not_ use wlroots? nothing against wlroots, but I would like understanding Wayland itself better first. I already created a minimal compositor with the help of https://wayland-book.com, but don't have anythign that actually displays pixels on the screen.
<guacamolie>
(I hope this channel is right for asking questions like these, please tell me if otherwise)
<guacamolie>
s/understanding/to understand/
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
<soreau>
guacamolie: you might be looking for weston, the wayland reference compositor
<emersion>
it's not the reference compositor, soreau
<emersion>
weston and wlroots have the same level of complexity, i'd say
<soreau>
emersion: when did this change?
<emersion>
i don't know of a minimal compositor
<emersion>
soreau: a few years ago
<soreau>
emersion: so are folks calling something else a reference compositor? or there is none
<emersion>
there is none
<soreau>
well when I need to refer to something that isn't wlroots, I use weston
<soreau>
so in this since, I guess it's still the reference compositor, to me
<soreau>
and this won't likely change :)
<soreau>
sense*
privacy has joined #wayland
<guacamolie>
hmm, I see
<guacamolie>
maybe I could go back in the git history of one of these projects to find an implemention from 'the simpler days'?
<soreau>
you could, but you might have to pair it with older dependencies, depending..
fossdd has quit [Ping timeout: 480 seconds]
<emersion>
you'll also find mistakes that were corrected after
<guacamolie>
true
<guacamolie>
I think it's probably best for me to go with tinywl anyway and try to best understand what wlroots is doing
fossdd has joined #wayland
<emersion>
and you'll find pretty old protocol versions
<guacamolie>
soreau and emersion: thanks
<soreau>
guacamolie: yea I think tinywl is your best bet. If you have further questions about it, check the wlroots headers or ask in #wlroots on libera chat
<guacamolie>
will do, thanks!
fossdd has quit [Ping timeout: 480 seconds]
aknot has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
julio7359 has joined #wayland
Leopold_ has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
Company has joined #wayland
Brainium has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
<Consolatis>
orowith2os[m]: gtk-shell is some private "unofficial" wayland protocol. I would not bet on it being implemented by a majority of compositors. The xdg-activation protocol seems like the right solution to your problem, when you have keyboard focus you can request a valid xdg-activation token from the compositor which you can then use in another window to request activation.
<Consolatis>
This is done to prevent unwanted focus stealing. Some compositors apparently also have a second use of the protocol in that they use it as an "urgent" hint if the token is not "valid" (e.g. the application didn't have keyboard focus when requested)
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
fossdd has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
soreau has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
Consolatis: interesting
<orowith2os[m]>
I was looking for the "urgent" bit, and I was aware gtk-shell is meant to be "private", so that's great to know
<orowith2os[m]>
well, me, and a valy_, wherever they may be
<emersion>
compositors will usually mark your window as urgent if you activate with a token which doesn't have focus
<orowith2os[m]>
I assumed it was assumed to always be either a protocol error or ignored if the token isn't valid
<orowith2os[m]>
seems like a good opportunity to update the docs if that isn't the case
<orowith2os[m]>
on a related note, what does a token look like? depends on the compositor, I assume, but what does e.g. wlroots or kwin do?
<orowith2os[m]>
any1: that seems like a horrible way of seeing if you can force-resize an output
<vyivel>
orowith2os[m]: just a random unique string
<any1>
orowith2os[m]: It is, but it's the only way as is.
<Consolatis>
any1: IMHO the information should not be "is headless" but rather "support custom modes"
soreau has joined #wayland
<orowith2os[m]>
extending wl_output would probably be the best bet
<emersion>
any1: why do you need this info?
<any1>
emersion: VNC servers can resize the desktop based on the client's window size
<orowith2os[m]>
also, I'd recommend other than abusing Wayland for that, look to the RemoteDesktop portal
<orowith2os[m]>
and add a "Resize" method
<emersion>
right
<any1>
If the output is a physical one, we want to disable this feature; otherwise allo users to resize at will
<emersion>
any1: when do you need to know?
<emersion>
at VNC connect time?
<emersion>
VNC client connect time*
<emersion>
or after?
<orowith2os[m]>
or both?
<orowith2os[m]>
though after probably covers that
<any1>
Emantor: Actually, just when the client requests a resize
<any1>
err, emersion
<any1>
soz, Emantor
<emersion>
i was going to say that handling failures should be enough
<Consolatis>
^ or maybe have a capabilities bitset in either of the protocols with caps like rotation | custom refresh rate | custom mode | ..
<emersion>
but on DRM this will result in weird stuff
<orowith2os[m]>
I'd actually love to see if some RemoteDesktop stuff could be sorted out - and looking at the portal website, it could use some touching up to hide "old" methods too :v
<Consolatis>
orowith2os[m]: there are compositors out there that do not use / require dbus. For those cases there still needs to be a portal implementation that then has to talk to the compositor via a wayland protocol
<orowith2os[m]>
Consolatis: for those compositors, they can use their own special wayland protocol, and build the portal on top of that
<orowith2os[m]>
it's not a new thing
<orowith2os[m]>
the wlroots portal does that
qaqland_ has joined #wayland
<Consolatis>
any1: xdg-desktop-portal wrapper for wayvnc?
<orowith2os[m]>
Consolatis: also, even *if* we had to make a wayland protocol for those compositors, the RemoteDesktop portal still needs to be expanded to support the resizable outputs feature
<orowith2os[m]>
so might as well just sort that out ASAP
<orowith2os[m]>
especially considering that's how most RDP clients work
<Consolatis>
there are already (private) wayland protocols for that, it is how wayvnc works
qaqland has quit [Ping timeout: 480 seconds]
<any1>
wayvnc is a wayland client. It hasn't jumped on the dbus and never will.
<orowith2os[m]>
ah, I completely forgot this was in the context of wayvnc. and what its goals were.
<orowith2os[m]>
If it's not a feature on the RemoteDesktop portal, I would love to see it there too
<any1>
But if someone wants to create some xdg desktop portal thing based on Neat VNC, I might help out.
<emersion>
any1: i wonder if some wayland protocol to create and manage virtual outputs would be better
<any1>
emersion: Actually, yes, I have considered this
<orowith2os[m]>
rather than jumping right to new protocols, why not go to wlr-output-management?
<orowith2os[m]>
and just expand that
<emersion>
because the use-case is different
<emersion>
wlr-output-management is for tools that configure your outputs, like a settings app
<emersion>
it's not really designed for the VNC use-case
<orowith2os[m]>
is that not what the use case here is? just with some necessary detection of features
<emersion>
nope
<orowith2os[m]>
would the current protocol not already work for that, actually?
<any1>
emersion: A virtual output could even be an ext-image-source-v1 that renders straight into screencopy buffers. ;)
<emersion>
that wouldn't be screencopy anymore
<emersion>
hm, or maybe it would
<emersion>
yeah, i suppose it could work
<any1>
Let's not get tied up by the name of the protocol. :)
<emersion>
right
<orowith2os[m]>
I don't really see why zwlr_output_head_v1 can't have a is_virtual event, being a bool, to see if resizing it to any arbitrary size is appropriate
<orowith2os[m]>
since it is an output
<Consolatis>
I still don't think that an output being virtual or not is what clients are actually interested in though, so being more specific like "supports any custom mode" seems more appropriate
<orowith2os[m]>
in the end, it gets the end result you want: is the output able to support any arbitrary mode?
<emersion>
because VNC servers need more ideally
<Consolatis>
until somebody else has a different use-case for detecting virtual outputs and then assumes that based on some implementation this assumption always holds for all implementations
<emersion>
ideally VNC servers need to be able to create virtual outputs as well
<any1>
Consolatis: The DRM backend supports custom modes (I think?). It just fails if the mode isn't actually supported.
<any1>
Consolatis: so we don't really want to mess with that. The idea is that physical outputs shouldn't be disrupted
<Consolatis>
well, then I'd say it may support custom modes but not *any* custom mode and thus would be false / not set
<Consolatis>
a cleaner solution would indeed be to have VNC servers (or related applications) create the virtual output