ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
BenjaminBreeg has quit [Remote host closed the connection]
BenjaminBreeg has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner_ has quit [Ping timeout: 480 seconds]
Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest6802
Brainium has quit [Quit: Konversation terminated!]
Guest6556 has quit [Ping timeout: 480 seconds]
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
tawonga has quit [Read error: Connection reset by peer]
tawonga has joined #wayland
Guest6802 has quit [Remote host closed the connection]
<zzxyb[m]>
Is it better to add isprimaryoutput to the zxdg_output_manager protocol?client needs to know the change information of the primary screen of the wayland server
rgallaispou has joined #wayland
sima has joined #wayland
mvlad has joined #wayland
<kennylevinsen>
zzxyb[m]: there is no concept of primary output in Wayland
<zzxyb[m]>
<kennylevinsen> "zzxyb: there is no concept of..." <- but libraries like qt have the concept of primary screen,shouldn't the primary concept be expanded?
<zzxyb[m]>
xcb also has xcb_randr_get_output_primary, should we consider it?
<zzxyb[m]>
or should this be handed over to kwin or wlroots to make custom protocols?
<kchibisov>
I think it was discussed though the years on wayland-protocols, so you can read on it there.
<zzxyb[m]>
ok thanks！
<kchibisov>
The primary output concept is just exposing bad behavior, because some games try really hard to stick to so called primary output.
<kchibisov>
Most requests have an option to pass `nil` instead of wl_output, so it'll try to pick some output (preferred by compositor) automatically.
<zzxyb[m]>
but for multi-screen mode, how the application should be displayed on the primary screen is useful.like ike kde there is kde-primary-output-v1.xml.there may be some features when there are multiple screens, such as the taskbar on the primary screen
<zzxyb[m]>
there will always be normal apps that want to show up on the primary screen
<kennylevinsen>
apps do not have any control over where they are shown. the compositor can internally prioritize displays however it likes.
<kennylevinsen>
(although making stuff appear on the "primary" output is - in my opinion - really bad UX on the platforms that do it. If I'm focused on screen X, triggered menus and apps shouldn't open on screen Y >.>)
<kchibisov>
kennylevinsen: they could refuse to leave the output as well.
<kchibisov>
I remember some games move back when you try to move them away from primary output.
<kennylevinsen>
hah, that sounds horrible
<kennylevinsen>
why fight the user?
<kchibisov>
I mean that's how game development works.
<zzxyb[m]>
kennylevinsen: yes,to expand, the primary screen is designed in some systems to be able to set any screen
<kchibisov>
They likely set all the state on each frame including output.
<kennylevinsen>
kchibisov: ah so they do it by accident? but that's certainly a good counterexample to having primary outputs
<kchibisov>
I'm not sure, I just seen games who refuse to launch on anything other than primary output.
<kchibisov>
That's the same with some games I ran in xwayland, they used dimensions of so called primary output.
<kchibisov>
while they were somewhere else.
<kennylevinsen>
zzxyb[m]: the concept when exposed to clients has been NACK'd over and over as being detrimental and without merit, but as kchibisov suggests, reading the discussions on the mailing list and gitlab would be better - it might offer a more nuanced response.
<zzxyb[m]>
ok
Cyrinux947 has quit []
Cyrinux947 has joined #wayland
<ofourdan>
For Xwayland (wrt the point about games running on Xwayland and not using the primary monitor), the Wayland compositor / X11 window manager can set the primary monitor using XRandR in Xwayland, that's what mutter does. Obviously, that does not help with Wayland native apps.
r00tobo has quit [Read error: Connection reset by peer]
sima has quit [Ping timeout: 480 seconds]
BenjaminBreeg has quit [Remote host closed the connection]
BenjaminBreeg has joined #wayland
alatiera has quit [Quit: Ping timeout (120 seconds)]
alatiera has joined #wayland
kts has joined #wayland
<drakulix[m]>
I totally missed doing a doodle for this weeks governance meeting...
<drakulix[m]>
Normally the selected date was announced on Monday, sooo.. should we re-schedule for next week instead?
Company has joined #wayland
<d_ed[m]>
Ok. I'm still going through my backlog of assigned tasks anyway
jmdaemon has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
kts has quit [Quit: Konversation terminated!]
nerdopolis has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
<zzxyb[m]>
<zamundaaa[m]> "zzxyb: fyi the kde protocol..." <- seems to find the same kind of issues:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/153
rasterman- has joined #wayland
rasterman- has quit []
rasterman- has joined #wayland
rasterman- has quit [Remote host closed the connection]
rasterman has quit [Ping timeout: 480 seconds]
rgallaispou has left #wayland [#wayland]
rv1sr has joined #wayland
rasterman has joined #wayland
Leopold__ has quit [Remote host closed the connection]
<wlb>
wayland-protocols Merge request !239 closed (xdg-shell: configure serial is not 0)
bittin_GUADEC has joined #wayland
<orowith2os>
How bad would it be if I learned Wayland and X by implementing (basically the polar opposite of) Xwayland?
<orowith2os>
My sanity is already at its limits, sooooo
<orowith2os>
I know you can just nest Weston, but bring more tightly integrated would be a goal
<orowith2os>
*being
<vyivel>
so like, get an xdg_toplevel and create a corresponding x11 window?
<orowith2os>
More or less
<vyivel>
sounds fun
<orowith2os>
The painful parts are, of course, going to be learning the convolutedness of X, and fighting the compiler (as I can't write very good C)
<vyivel>
considering that wayland is about policy rather than mechanism the translation should(?) be somewhat straightforward
<orowith2os>
It would be nice to have as much as possible only support Wayland, and have backwards compat by way of a compat layer
<orowith2os>
Less reason for things to support X backend
<orowith2os>
So I guess a better question would be, how much pain should I expect, and are there some decent (ideally modern) resources for learning both sides of the equation?
<orowith2os>
Hoping the Rust bindings hold up here, or some cursed mix of C <-> Rust is resorted to
Cyrinux947 has quit []
<kchibisov>
I'm still looking for resources to learn about X11 in a sane way.
<orowith2os>
Perfect! I'll be sure to get my therapist ready
<kchibisov>
The main issue is that stuff is simply not documented.
<kchibisov>
Like you have some documentation.
<kchibisov>
But some stuff could only be figured out from other folks doing X11 for years.
Cyrinux947 has joined #wayland
crombie has joined #wayland
<DodoGTA>
Does Xorg have reference counts?
<bittin_GUADEC>
heya
<orowith2os>
@DodoGTA a quick Google search shows some hits
<orowith2os>
So at least in some places
<orowith2os>
A gitlab search shows some references to it in docs
<DodoGTA>
orowith2os: I wonder if it's worse than COM though
junaid has quit [Ping timeout: 480 seconds]
<kchibisov>
DodoGTA: the thing is that some spec impl tied to specific lib.
<kchibisov>
So you have to read the code pretty much most of the time to understand why something works like that.
<kchibisov>
E.g. when trying to use xinput2 you'll break xim, because it's all done in xlib and xlib only does xinput.
<kchibisov>
Even though, nothing really stops from using xinput2 with xim, because you can build XKeyEvent from the xinput2 event for keyboard just fine.
<kchibisov>
So you'd have to go with xcb, for example, but then you realize that you don't have xim anymore and you have to wire it up yourself.
<kchibisov>
it's just all over the place.
<kchibisov>
With wayland you just read spec write what is written and 99% of the time you're good.
<kchibisov>
And x11trace compared to WAYLAND_DEBUG is just not helping at all.
<kchibisov>
You could also find during development that XWayland behaves way more sanely than real X.org.
<kchibisov>
e.g. XPresent only works the way you could expect from it to work only under XWayland, with real X it's just doing something completely arbitrary.
<kchibisov>
I remember being told here that I could use XPresent to implement something similar to frame callbacks, and it really workde the same on XWayland but on real X it was just not delivering any of the events any more.
<emersion>
wlroots does that
<emersion>
it works on regular X as well
JakeSays1 has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit []
junaid has joined #wayland
BenjaminBreeg has left #wayland [#wayland]
mvlad has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
<kchibisov>
emersion: I mean it works, but not like on wlroots.
<kchibisov>
You simply can't rely whether your window was presented or not anymore.
<kchibisov>
You can only use timing.
<kchibisov>
So your frame rate goes from display refresh rate(on wlroots) to 20 (that was in my case with i3 and default X).
junaid has joined #wayland
rv1sr has quit []
<kchibisov>
Though, I've lost a logs when debugging it, but basically only `ust/msc/sbc` where stable, the `CompleteNotify` event worked completely different.