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
Sheilabillyinvest[m] has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2022-05-13 06:07:05)]
rv1sr has quit []
tzimmermann_ has quit []
tzimmermann has joined #wayland
Guest513 is now known as go4godvin
caveman has joined #wayland
sych1ll has joined #wayland
sychill has quit [Read error: Connection reset by peer]
rv1sr has joined #wayland
eroux_ has joined #wayland
eroux has quit [Read error: No route to host]
duxsco has joined #wayland
caveman has quit [Quit: caveman]
<emersion>
pq, btw, it would be nice to have a list of EDID things you're interested in for color management
<erle->
is there anything manual required to use Wayland plus nvidia proprietary on debian-ish systems?
<jadahl>
erle-: that depends on the DE/compositor you're using
neonking has quit [Remote host closed the connection]
<erle->
just standard gnome
<erle->
but GDM does not show the option
<erle->
it does show on other machines without nvidia prop driver
neonking has joined #wayland
<jadahl>
erle-: a topic of a GNOME IRC channel, but it should be selectable via GDM in gnome-42 unless something goes wrong
rasterman has joined #wayland
<pq>
emersion, ah, will do
<erle->
jadahl, I asked in Debian yesterday but they just asked who is using Wayland already?
<erle->
(im using it for five years now)
<pq>
erle-, I think the Wayland option may have been hidden in older GNOME versions with NVIDIA proprietary, as supporting that driver needs special code in the compositor the last I heard.
<dottedmag>
A heads-up about EDID: on Apple M1 display controller hides EDID parsing from the CPU, so either KMS driver will have to generate fake EDID, or compositors will have to learn that not all outputs have EDID. That display controller provides enough information about available modes etc, just not the raw EDID.
<dottedmag>
Is there a precedent for handling these kinds of controllers?
<pq>
dottedmag, there is no precedent, and EDID is in the kernel UAPI, so fake EDIDs it is then.
<pq>
how very very VERY unfortunate
<pq>
or, you could not expose EDID at all, and leave userspace without any extra information
<pq>
or, take the long route, and expose everythign there is about EDID as KMS properties. Which is probably not feasible, and also would make the kernel parse EDID for things it doesn't need.
<pq>
there's no good option
<dottedmag>
Display controller there also handles tiled monitors. Does the current generation of EDID allow expressing arbitrary resolutions? 5120x2160 will be seen by CPU as a single output.
<dottedmag>
Not as two tiles.
<dottedmag>
(well, talking about a specific tiled monitor, of course)
<pq>
userspace does not parse resolutions from EDID, kernel exposes a mode list, so that detail is not a problem
<dottedmag>
That's a relief, at least. What information do compositors care about in EDID?
<pq>
monitor identification: make, model, serial number, EDID checksum
<pq>
maybe colorimetry
<jadahl>
dottedmag: the kernel needs to expose the tile property which will contain tile sizes. the compositor will then find the right modes to configure the two tiles as one monitor
<pq>
supported HDR modes and their supported parameters, once HDR support arrives
<dottedmag>
pq: Aha. This should be doable.
<pq>
min/max refresh rates for VRR I guess
<dottedmag>
jadahl: We're talking about Apple M1 display controller. It hides tiles from the CPU.
<jadahl>
dottedmag: so a tiled monitor will appear as a single crtc/connector?
<jadahl>
with a "fake" mode etc?
<pq>
physical screen size I'm not sure if there already is a KMS API for it
<pq>
dottedmag, you can look at your EDID with edid-decode, disregard all resolution and timing information, and see what's left.
<dottedmag>
jadahl: Not sure what is fake and what is not. Display controller there takes care of exposing outputs, and if one of the outputs is connected to a tiled monitor, that output will be reported to have the full monitor's resolution. It also takes care of enumerating possible (joint) resolutions on that monitor.
<dottedmag>
pq: Sounds good, thanks.
<jadahl>
dottedmag: that sounds like it "fakes" it more or less then, meaning no need from the compositor to handle the tiling
<dottedmag>
jadahl: That is right, no need to do anything special in compositor.
<dottedmag>
Also refresh synchronization is handled by the display controller
<dottedmag>
(obviously, as there are no two outputs)
Arnavion has quit [Remote host closed the connection]
heeen has joined #wayland
Arnavion has joined #wayland
<heeen>
what do you have to do as a matrix user to be able to write
<emersion>
register an OFTC account and login
<heeen>
are matrix bridged users muted by default?
<emersion>
matrix doesn't properly propagate the IRC error messages
<heeen>
hmm oftc I configured with a client cert
<heeen>
matrix I don't know how to do that
rv1sr has quit []
<pq>
I think non-logged-in users are muted on some channels.
<heeen>
Does the recent nvidia kernel module source release help with wayland support? like the EGLStreams vs DRM,GBM,KMS or what the current state is
<pq>
No.
lxsameer3 has joined #wayland
<pq>
maybe it helps creating a proper upstream driver over a few years
<heeen>
I read that it being GPL would allow it to consume GPL APIs in the kernel or something to that effect
rv1sr has joined #wayland
<heeen>
wait is it GPL
jmabr has joined #wayland
<heeen>
Except where noted otherwise, the individual files within this package are
<jadahl>
heeen: dual licensed GPL/MIT iirc
<heeen>
licensed as MIT:
<heeen>
is EGLStreams vs GBM handled in the kernel module or the userspace
<emersion>
it's a user-space thing, but also interacts with KMS
<emersion>
GBM requires DMA-BUF support
<emersion>
but NVIDIA supports both now
<emersion>
we even got the Vulkan ext in the latest driver beta
<heeen>
emersion: got a link to discussion around it?
<emersion>
ot sure what you're looking for
<emersion>
not*
<kennylevinsen>
heeen: the GBM support is not new, you can probably find some older articles about it
<kennylevinsen>
the new kernel-mide driver has no immediate consequence to end-users, but will lead to some nicer things in a few years
<kennylevinsen>
*kernel-mode
<heeen[m]>
test
<jadahl>
test passed
<erle->
pq, I am on unstable with recent kernel, recent driver and recent gnome
<jadahl>
erle-: if you want to "debug" why you don't get the option you can come to #gnome-shell on irc.gnome.org and we can dig into what is going wrong
Azem has joined #wayland
heeen[m] is now known as heeen[m][m]
<erle->
jadahl, that's a good next step
flacks has quit [Quit: Quitter]
flacks has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110_ has quit [Remote host closed the connection]
<kennylevinsen>
right, but what were you using as trigger
<bl4ckb0ne>
i think thats what i failed to understand
<any1>
You could use pipe() and a thread that writes into it.
<bl4ckb0ne>
nothing triggers it, im waiting for it to be triggered
<bl4ckb0ne>
im waiting for somebody to tell me "hey you can poll your events now buddy"
<ifreund>
nothings going to trigger it then
<bl4ckb0ne>
so that's probably why its not working eh
<kennylevinsen>
you have two options:
<ifreund>
to be able to tell you that, the event loop needs an fd that will become readable when there are events for you to read
<kennylevinsen>
1. find out what openxr waits internally and see if you can expose that as an fd, if it isn't already
<kennylevinsen>
2. have a thread loop on xrPollEvent or similar and write a byte to a pipe whenever they wake
<bl4ckb0ne>
i think ill stay with what i have, wl_event_loop_dispatch then poll the XR events
<emersion>
there's xrWaitEvent
<bl4ckb0ne>
i dont see any mention of FD in the openxr spec
<any1>
Send them a patch then? :)
<emersion>
err
<bl4ckb0ne>
hm i dont see it in the spec
<bl4ckb0ne>
any1: thinking about it
<kennylevinsen>
bl4ckb0ne: dispatching two event loops in order is bad - if that's your only option, then you're probably better off with a different thread to manage openxr...
<kennylevinsen>
but there should really just be a way to poll :/
<bl4ckb0ne>
agreed
<emersion>
there's XrPollEvent which doesn't block but doesn't say when there's a new event