ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
ppascher has quit [Ping timeout: 480 seconds]
ppascher has joined #wayland
ybogdano has quit [Read error: Connection reset by peer]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Consolatis_ has joined #wayland
Consolatis is now known as Guest923
Consolatis_ is now known as Consolatis
Guest923 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
<DemiMarie>
yshui: also, if a protocol indicates that a situation is a protocol error, the protocol should also specify the specific error that should be sent. Otherwise, that is a bug in the protocol; please report it.
eroc1990 has quit [Ping timeout: 480 seconds]
yar has quit [Quit: yar]
yar has joined #wayland
eroc1990 has joined #wayland
sav10 has quit []
danvet has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
hardening has joined #wayland
Compy_ has quit [Remote host closed the connection]
jgrulich has joined #wayland
dcz_ has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
shoragan_ has joined #wayland
shoragan is now known as Guest933
shoragan_ is now known as shoragan
rv1sr has joined #wayland
tzimmermann has joined #wayland
sav10 has joined #wayland
rasterman has joined #wayland
floof58 is now known as Guest935
floof58 has joined #wayland
Guest935 has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
manuel1985 has joined #wayland
MajorBiscuit has joined #wayland
kts has joined #wayland
<pq>
emersion, I read that GPU mux uAPI proposal and it seems fine to me. What I don't understand is how most of the listed problems are even problems.
<pq>
emersion, e.g. a display server would not even initiate a mux switch if it was not already DRM master on both involved devices, so I'm not sure where any validation/auth issues could come up.
Leopold has joined #wayland
Guest933 has quit []
mvlad has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
sav10 has quit []
eroux has joined #wayland
<jadahl>
pq: one of the problems is that the drm resource list is empty until you turn the mux to switch to the other device. not until after the mux switch will you get to know about e.g. planes, etc
<jadahl>
or perhaps not empty, but partially empty
<pq>
jadahl, huh? How is that possible? Why would the device resources have any dependency to a mux setting?
<pq>
I can understand that connectors could come and go, but not planes or CRTCs.
<jadahl>
pq: if you want to render to the other gpu, flip the mux, you don't have information how to render (e.g. plane formats, whether there is a gamma_lut)
<pq>
and I would not even necessarily have connectors come and go, but just make them disconnected
<jadahl>
it's the second last known problem listed
<pq>
jadahl, yeah, what I mean is, that sounds nonsense. Why does the device hide all its resources until the mux is switched to it? How does that even work when you have multiple muxes for the same device?
<vsyrjala>
drm even prevents adding new resources after the device has been registers
<jadahl>
yea I agree, it makes sense that it should be exposed up front
<vsyrjala>
registered
<pq>
What *else* is the mux controlling than where a CRTC output signal is going?
<vsyrjala>
maybe the problem is that you don't know which connectors are going to connect/disconnect, so you can't necessarily figure out which crtc/plane you will need ahead of time?
<pq>
I thought the whole point of the new thing is to allow the device to be powered on regardless of mux setting, among other things.
<pq>
vsyrjala, the proposal includes UAPI to tell userspace exactly that.
<pq>
how could the kernel not know that
<vsyrjala>
hmm. i can't think why you'd even need that though. you flip the switch, wait for connectors to become connected, and the light them up as normal
<pq>
exactly
* vsyrjala
hasn't actually read the wall of the text
<vsyrjala>
maybe i should. but more urgent stuff now...
<JEEB>
:)
<pq>
I think there is some huge underlying unwritten assumption in that wall of text.
nik has joined #wayland
ofourdan has quit [Ping timeout: 480 seconds]
<pq>
emersion, since you proposed labels and wayland-devel@ list, are you ready to announce libdisplay-info?
<pq>
cc swick ^
jmdaemon has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
kts has quit [Quit: Leaving]
MajorBiscuit has quit [Quit: WeeChat 3.6]
MajorBiscuit has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.6]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
MajorBiscuit has joined #wayland
<pq>
emersion, would be nice if ascent's drm_info repo would fail to build saying "you have an outdate git remote" instead of "a label can only be part of a statement and a declaration is not a statement". :-p
<pq>
took me a while to realize I need to switch remotes to get it to build again
cvmn has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
caveman has quit [Remote host closed the connection]
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
manuel1985 has quit [Quit: Leaving]
<emersion>
pq, hm, where does that error come from?
<pq>
I guess because it somehow doesn't find the subproject drm_fourcc.h, and my system header is too old.
<pq>
even after I explicitly told it to download subprojects
<pq>
and the problem does not appear in your repo
<emersion>
hm, weird
<emersion>
not sure what would cause that
<pq>
meson was also very unhappy about trying to access files in subprojects dir
<emersion>
i think my repo has fixes for newer meson, yeah
<pq>
quite likely that's the thing
<emersion>
maybe i can add a warning() in the GitHub repo to indicate the migration
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
___nick___ has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
Leopold has joined #wayland
Company has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
tzimmermann has quit [Quit: Leaving]
floof58 is now known as Guest967
floof58 has joined #wayland
Guest967 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
gildekel has joined #wayland
sav10 has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
shankaru has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
danvet has joined #wayland
sav10 has quit []
sav10 has joined #wayland
shankaru has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
j_ml[m] has joined #wayland
jmdaemon has joined #wayland
<bwidawsk>
I was looking for some suggestions on implementing a tray/bar. I see a reasonable WLR path for this (layers) and Plasma's roles seem to also fit the bill. Am I missing anything else in existing protocols for handling these kinds of above everything surfaces?
<bl4ckb0ne>
wlr_layer_shell is probably the best fit for the job, i dont think you're missing anything
hardening has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<bwidawsk>
bl4ckb0ne: hmm, thanks. I really don't need layers for anything else, so I had been hoping for something more minimal
floof58 is now known as Guest991
floof58 has joined #wayland
Guest991 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
<bl4ckb0ne>
what do you mean by more minimal
<soreau>
if you're looking for a list of toplevels, you can use wlr-foreign-toplevel-management
dri-logg1r has joined #wayland
dri-logger has quit [Read error: Connection reset by peer]