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
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
ishanjai- has joined #wayland
floof58 is now known as Guest4881
floof58 has joined #wayland
jmdaemon has joined #wayland
ishanjain has quit [Ping timeout: 480 seconds]
Guest4881 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
manuel_ has quit [Read error: Connection reset by peer]
molinari has quit [Remote host closed the connection]
molinari has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
molinari has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
<DemiMarie>
DodoGTA: Firefox should be processing messages from the Wayland socket even if the window is stuck in the debugger.
agd5f_ has quit []
agd5f has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #wayland
kts has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
Company has quit [Quit: Leaving]
tzimmermann has joined #wayland
nullpointer128 has joined #wayland
jmdaemon has joined #wayland
danvet has joined #wayland
pochu has joined #wayland
sozuba has joined #wayland
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pq>
emersion, re: libdisplay-info version, I don't know really. I haven't read the semver specification well enough to answer that. I just had a feeling it might require 0.2.0.
<emersion>
yeah, we've talked about this at last XDC
<pq>
OTOH, since it's basically changing the name of display-info to libdisplay-info in pkg-config, that already accounts for the... "break".
<pq>
emersion, so, like in many comments I make, just asking due diligence
<jadahl>
pq: libliftoff helping offloading color management pipelines was something discussed in the conference call we had about that last fall. but it's hard to come up with an api that fits every type of hw
ofourdan has quit [Ping timeout: 480 seconds]
<pq>
jadahl, right, and yes, I can totally see that problem.
<pq>
jadahl, in Weston I'm approaching that same problem from the opposite direction: what do applications and the compositor need, rather than how to enable all existing hardware.
<jadahl>
pq: figuring that out seems crucial to then figure out how to best interact with kms
<pq>
yes, which is why I am not at all in a hurry with asking for more KMS color features.
<pq>
or even using the existing KMS properties
<jadahl>
understandable
<pq>
but I do want to be able to drive a HDR monitor in a known way with KMS :-)
<pq>
hence the "Colorspace" property discussion is is interesting to me right now
<jadahl>
yea, have to have support to get event the most basic thing working, but the harder part with libliftoff etc is offloading to planes
<JEEB>
pq: I've been laughing at how ad-hoc it seems like HDR vs colorspace property implementation was
<JEEB>
so I could f.ex. on AMD say my transfer is PQ
<JEEB>
but not say my primaries are BT.2020
<JEEB>
while to properly signal BT.2020+PQ in output you need both
<JEEB>
of course monitors seem to interpret that if you say PQ it's BT.2020 probably (or then the AMD driver is doing stuff behind your back)
jmdaemon has quit [Ping timeout: 480 seconds]
<JEEB>
meanwhile my old x230 can do colorspace, but not HDR
<pq>
JEEB, I know :-D
<JEEB>
:)
<pq>
it's almost like "what's the minimum we need to fool the monitors to do what we want for one use case" - I can understand how people get there, it's purely practical for the one immediate need.
<JEEB>
yup
<JEEB>
also since x11 and wayland didn't and still don't support it -> no need. vulkan extension can go completely around KMS after all in the graphics driver
<pq>
only in proprietary drivers
<JEEB>
oh and the vulkan extension I found also kinda weird. it says HDR metadata, but then apparently sets colorspace and transfer as well?
<JEEB>
a lot of implicit stuff going rounds :D
<JEEB>
while on d3d11 I set my swap chain colorspace to BT.2020+PQ, and then if I have HDR metadata I set that separately as well.
CodeSpelunker has joined #wayland
<pq>
but it works, right? Industry standards, right? right?
<pq>
oh, your monitor only does HLG, hmm... nah, no-one makes such monitors. right? Oh but HLG also is de facto BT.2020. No problem!
<JEEB>
on macOS that can also be done, but I think they prefer linear fp16 scRGB now. windows also supports this, but since they haven't voiced a preference and the BT.2020 + PQ setting allows for seeming passthrough of PQ values that's what I default to atm
<JEEB>
:)
ofourdan has joined #wayland
paulk has quit [Quit: WeeChat 3.0]
paulk has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
CodeSpelunker has quit [Quit: CodeSpelunker]
rasterman has joined #wayland
d__ed has quit [Remote host closed the connection]
rasterman has quit []
rasterman has joined #wayland
ofourdan has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
fmuellner has joined #wayland
devilhorns has joined #wayland
naveenk2 has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
OMGOMG has quit [Read error: Connection reset by peer]
<pq>
emersion, did you intend to not cc dri-devel and linux-media lists with the libdisplay-info 0.1.1 annoucement?
<pq>
or are all announcements only on wayland-devel from now on?
<emersion>
the release template and docs don't cc these lists
<pq>
is that intentional?
<emersion>
i don't want to spam these other lists, but i also see why subscribers to these other lists would be interested
<pq>
yeah, maybe it's fine, but linux-media could use just the first announcement :-)
<emersion>
i will forward the 0.1.0 announcement then
<pq>
sounds good, and maybe also mention that further announcements are only on wayland-devel and that 0.1.1 is out already
<pq>
who knows, maybe someone would ask to cc linux-media in the future too
<naveenk2>
HI All, how do I run tests which are under weston/tests/* ? I want to run few tests such as color-icc-output-test.c
<pq>
naveenk2, 'meson test' runs them all. Or you can simply run any single binary itself. Each binary also has --help.
<naveenk2>
great!
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
<swick[m]>
the problem is that for hardware people HDR support is their fancy scanout hardware being able to offload the conversions so they want to expose that stuff right now
<swick[m]>
and then they just add it in a way that user space can't use it or only works on their hardware or whatever
<pq>
yeah
<pq>
Maybe they need to expose driver-specific UAPI and then the public API is some userspace library a la OpenGL and Vulkan. But that's also throwing all the existing KMS out the window.
<swick[m]>
I also don't know yet which exact transformations we will end up with in user space but pushing a new model where we can properly define the expectations from both user space and kernel would help a lot
<daniels>
tbf, whilst we don't want to compromise the long-term plan by having a random mish-mash of unusable stuff, having people actually be able to watch HDR movies or play HDR games in the interim would be a very good thing
<swick[m]>
yeah, that's why I want a Colorspace propert which does more magic in the kernel even though that's completely against my long term plans
<pq>
ah, Colorspace, yes
<swick[m]>
but that's why im advocating for a strict devision between the old and new stuff with a KMS cap
<daniels>
swick[m]: are you saying that I'm in favour of bad ideas, or that any interim solution is objectively bad, or are you just being snarky for the hell of it?
<pq>
the color pipeline off-loading is somewhat different though, we don't need it to make HDR videos and games work. It's for battery life instead.
<swick[m]>
daniels: neither? I think I agreed with you
<swick[m]>
pq: sure, but all the magic properties which we need to make HDR right now will make the offloading much worse to impossible
<pq>
that's fine :-)
naveenk2 has quit [Ping timeout: 480 seconds]
<daniels>
yeah, making the old/coarse-grained and new/fine-grained property worlds mutually exclusive does sound sensible - I suspect it would probably be better as a CM_EPOCH property which the client sets though, because otherwise with caps you'd end up having to have the kernel sanitise the CM props in order to handle transitions between clients? e.g. if you change from Kodi doing current-HDR to a compositor doing no CM, the kernel would
<daniels>
need to know to clean up the props that Kodi set and set them back to 'normal'
<vsyrjala>
i don't see why the old prop really matters at all. if you don't want to use it then don't
<vsyrjala>
we can postpone the decision whether to fully remove it or not
rasterman has quit [Quit: Gettin' stinky!]
<pq>
what does "not use it" mean for a property that cannot be without a value?
<vsyrjala>
it'll be left with the default, which lets the driver do whatever
alarumbe has quit [Quit: ZNC 1.8.2+deb2 - https://znc.in]
MajorBiscuit has joined #wayland
<pq>
ok. And switching between different KMS clients is so niche that it can continue to be completely ignored like it has been.
<emersion>
i'd be in favor of disabling the old props when the cap is enabled
<emersion>
like DPMS
<emersion>
otherwise it's just more edge cases to think about
<emersion>
ie. the client can ask for non-sensical and self-contradictory configurations
<pq>
and that becomes a real problem when it accidentally does something the client relies on :-)
<vsyrjala>
i don't consider it much different than eg. providing bogus hdr metadata. the kernel won't save you from that footgun
<emersion>
providing bogus HDR metadata is less of an issue, since the kernel just passes it through
<pq>
vsyrjala, it's not about the client shooting its foot. It's about the client *aiming* its foot and hitting a bullseye instead.
<vsyrjala>
the kernel also just passes through the colorspace prop
<emersion>
why build a footgunny api on purpose?
<emersion>
is there a use-case where it's useful to have both old and new?
<vsyrjala>
we already have it. seems to me people are needlessly stuck on this point when they should be writing patches for the new prop
<emersion>
i mean this stuff is already complicated enough, i don't see why we need the api to be even more complicated to think about just for fun
<swick[m]>
I also really don't see what the benefit is for keeping everything around
<swick[m]>
its just more complexity for the sake of it
<vsyrjala>
not sure adding yet anorher cap in the mix is going to simplify anythging. but if someone wants to write a patch for that then i guess at least we'd have something real to talk about
<swick[m]>
the problem with that is that I'm not a kernel developer and certainly don't have the time to become one right now
<swick[m]>
the reason why I'm involved here at all is because the kernel developers manage to create interfaces which are literally unsable
<swick[m]>
and a few more properties which kernel developers wanted to add were also going to be unsable
<vsyrjala>
my take is to 1) add the new prop 2) ignore the other mess for now, so that we can at least make *some* progress
<vsyrjala>
designing the new prop doesn't depend on solving the mess
<swick[m]>
true. i think we can all agree to that
<emersion>
yup
ofourdan has joined #wayland
___nick___ has joined #wayland
<swick[m]>
daniels: with the CM_EPOCH approach at least the kernel knows when a client needs all the magic properties to do their thing and it can reset everything to reasonable values whereas a combination of new and old properties will result in conflicting magic properties (old) and explicit properties (new) being set...
<swick[m]>
I really don't want to think about the semantics in that case
<pq>
What's the difference between CM_EPOCH property and a client cap again? Except clients who don't understand CM_EPOCH would never reset it, while the client cap is tied to the client.
<swick[m]>
mh, good point. I think I really want a cap then...
<emersion>
yes, client cap
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
alarumbe has joined #wayland
paulk-ter has joined #wayland
paulk-bis has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
<ukiran>
Hello
naveenk2 has joined #wayland
<ukiran>
Am seeing an visual artifact issue on the ubuntu-22.04.1 version when maximizing/minimizing the window with the bottom-right corner using mouse
<ukiran>
looks to be window decoration issue.
Cyrinux9 has quit []
Cyrinux9 has joined #wayland
<ukiran>
does anyone seeing this issue ?
<DodoGTA>
DemiMarie: Then why does it still error out with that "error in client communication" thing when hovering over some elements in the Inspector (which causes a freeze) and moving around the mouse a bit?
naveenk2 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
They're probably accidentally blocking their main thread. They do have a bunch of things that end up running on the main thread for architecture and "web" reasons...
<kennylevinsen>
All proposals in this area effectively extend the time until the connection dies, but do not change the fact that blocking will eventually lead to terminated connections
ofourdan has quit [Remote host closed the connection]
naveenk2 has joined #wayland
<DemiMarie>
DodoGTA: The correct thing for Firefox to do would be to either handle the Wayland socket in a separate thread or run a separate message loop that only handles Wayland events. Please report this as a Firefox bug.
jmdaemon has joined #wayland
<kennylevinsen>
Well, to run whatever blocks in a different thread. You usually call the event loop handling the Wayland display for the main thread
rv1sr has joined #wayland
<kennylevinsen>
but one cannot blame Firefox entirely if high-resolution input (gamer mice) is involved: then you have Firefox doing something bad by blocking, but the compositor is also spamming the process at very high rates making even a short pause in reading overflow the buffer... So, improvements needed on both sides.
<kennylevinsen>
blocking very momentarily needs to be possible - one has to dispatch the queue after reading after all
parazyd has joined #wayland
<parazyd>
Hey
<parazyd>
I got a graphics tablet and I'm trying to get it working with libinput (on X11)
<parazyd>
After battling with my kernel I think I finally got all the right drivers, and the device seems to be recognised
<parazyd>
But now I'm struggling with libinput understanding it
d_ed has joined #wayland
<parazyd>
It gives me the following error when I connect my tablet: HUION Huion Tablet_H580X: libinput bug: missing tablet capabilities: resolution
<parazyd>
I've tried adding _something_ to evdev.hwdb to no avail
<parazyd>
Any clues?
<emersion>
parazyd: maybe ask whot in #wayland on OFTC
<emersion>
oh
<emersion>
we are in #wayland on OFTC, it turns out :P
<parazyd>
haha
<parazyd>
Yeah the /topic on libera pointed me here
<emersion>
so used to having these questions in #sway
<parazyd>
oh so there are ppl with this problem?
<emersion>
no, i mean this kind of question, not this specific one, sorry!
<parazyd>
Would "evdev:input:b0005v0000p0000e0000*" be a valid hwdb entry?
jmdaemon has quit [Ping timeout: 480 seconds]
Net147 has quit [Ping timeout: 480 seconds]
<parazyd>
oh I was using the wrong one
<parazyd>
hah nice
<parazyd>
1) Disconnect tablet, 2) find /sys | sort > first , 3) Connect tablet, 4) find /sys | sort > second , 5) diff -up first second | grep modalias
tzimmermann has quit [Quit: Leaving]
<parazyd>
ok, semi-related. Is there a way I could use it specifically as a tablet input but _not_ a mouse pointer?
jmdaemon has joined #wayland
agd5f_ has joined #wayland
Net147 has joined #wayland
floof58 has quit [Quit: floof58]
floof58 has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
Net147 has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
Company has joined #wayland
agd5f has joined #wayland
sozuba has quit [Read error: No route to host]
jmdaemon has joined #wayland
d_ed has quit [Remote host closed the connection]
tent405 has quit [Ping timeout: 480 seconds]
Net147 has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
devilhorns has quit []
nullpointer128 has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.6]
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
agd5f_ has joined #wayland
junaid has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
nullpointer128 has joined #wayland
nullpointer128 has quit []
nullpointer128 has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
Arnavion has quit []
Arnavion has joined #wayland
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mvlad has quit [Remote host closed the connection]
Brainium has joined #wayland
Brainium_ has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
d42 has quit [Ping timeout: 480 seconds]
d42 has joined #wayland
that_guy has quit [Quit: I'M OUT]
that_guy has joined #wayland
andyrtr_ has joined #wayland
<DemiMarie>
kennylevinsen: “whatever blocks” is likely JavaScript. Moving Wayland to a separate thread is probably a much smaller change.
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
junaid has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
i did that in my compositor, with a lock it goes pretty well
DodoGTA has quit [Quit: DodoGTA]
nullpointer128 has joined #wayland
nullpointer128 has quit []
DodoGTA has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
<kennylevinsen>
DemiMarie: Firefox does not own the Wayland connection as it piggybacks off Gtk, so non-trivial to move things around
nullpointer128 has joined #wayland
<whot>
parazyd: you need a resolution for ABS_X and ABS_Y, that's usually a kernel driver issue and should be set there but you can override it with a hwdb entry. but given that your VID/PID are all zeroes, looks like your kernel driver isn't quite up to scratch yet
nullpointer128 has quit []
danvet has quit [Ping timeout: 480 seconds]
rv1sr has quit []
nullpointer128 has joined #wayland
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]