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
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
<pq>
emersion, bl4ckb0ne, it would certainly raise my eyebrow and make me suspect a bug if I saw wl_array without any call to wl_array_init().
<pq>
even if the code did the right thing, it would still cost me time to clarify those suspicions every time I read such code.
<pq>
*clear
<pq>
so I very much recommend using wl_array_init() always.
<pq>
You could also init a wl_list without calling wl_list_init() and be equally correct.
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
hegstal has joined #wayland
floof58_ has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
pnowack has joined #wayland
pnowack has quit []
pnowack has joined #wayland
chiragmm has quit [Remote host closed the connection]
<pq>
...just that with wl_list, you have to init with the pointer to itself, not zeroes. But the same thing.
jgrulich_ has quit [Remote host closed the connection]
jgrulich has joined #wayland
<emersion>
pq, initializing a wl_array might ne cumbersome if it's a global
<emersion>
be*
<emersion>
I think wl_array_init was a mistake btw
<emersion>
well a lot of wl_array is unfortunate
<emersion>
e.g. how wl_array_for_each iterates on pointers
<emersion>
I get why, but it's annoying in 99% of the cases
<emersion>
not only annoying, but also error-prone
floof58_ has quit [Ping timeout: 480 seconds]
floof58_ has joined #wayland
<pq>
emersion, I do hate globals, but if you need static initializer, then we should have one in libwayland-util.
<pq>
but if you calloc() a struct with a wl_array in it, then there really is no excuse to not call wl_array_init().
<pq>
unfortunate, sure, but C and all
<pq>
daniels, did we have any *good* example of a KMS property in Weston which is output/connector/crtc state and not plane state, which we program?
<pq>
I'm trying to figure out how to hook up the programming of HDR_OUTPUT_METADATA.
<pq>
and GAMMA, CTM, DEGAMMA (yes, I know I need to rewrite the whole gamma API)
<pq>
WDRM_CRTC_MODE_ID but that is with modesets only... WDRM_CONNECTOR_CONTENT_PROTECTION and WDRM_CONNECTOR_HDCP_CONTENT_TYPE...
<pq>
looks like I'll add new fields to struct drm_output_state for these
<pq>
do I need to refcount the blob ids...
flacks has quit [Quit: Quitter]
flacks has joined #wayland
ice9 has joined #wayland
floof58_ has quit [Ping timeout: 480 seconds]
floof58_ has joined #wayland
silver has quit []
Lucretia has quit []
Lucretia has joined #wayland
ice9 has quit [Ping timeout: 480 seconds]
floof58_ has quit [Ping timeout: 480 seconds]
floof58_ has joined #wayland
<daniels>
pq: hmmm maybe, blob IDs have EGL-like semantics, where destroying a blob ID makes that ID unavailable for future use, but the blob itself isn't destroyed until the last user is finished
<daniels>
as for good examples - no, I'm afraid not
<daniels>
as you've seen MODE_ID didn't really make any effort to generalise blob handling, because we don't care about lifetime tracking (they're too small to bother, are one-shot, and also mostly static), and there weren't any others at the time
<pq>
changing the blob contents runtime will likely be needed at some point
<pq>
i..e replacing the blob
<pq>
DEGAMMA, CTM, and GAMMA blobs would have similar usage patterns
<pq>
I could create a fully refcounted blob container while here if that seems necessary.
<pq>
hmm, I think I did half of both approaches, which may also be broken
<pq>
if the current blob is saved in drm_output, then why do we need the field in drm_output_state too?
<daniels>
it shouldn't be, really ...
<daniels>
mode_id only gets saved in drm_output to be alongside current_mode, which again only really works because it's generally static
<daniels>
something more dynamic definitely shouldn't be saved in drm_output
<daniels>
(I do not have a good suggestion as to where it should go)
<pq>
these CM&HDR blobs would be mostly static too
<pq>
but not as static as the mode blobs
<pq>
daniels, should drm_output_state::protection field not exist either? And drm_output_state::dpms?
<daniels>
why would they not exist? they're entirely dynamic ...
xexaxo has quit [Remote host closed the connection]
xexaxo has joined #wayland
<pq>
I see them being equally dynamic/static as the CM&HDR blobs - just that they are not blobs but stored by copy.
<pq>
re-creating blobs on every frame is something I'd avoid, sometimes they do need to be re-created.
<pq>
an animation switching from one color profile to another (night light?) is not unthinkable either
<daniels>
yeah, quite
<daniels>
but I think that suggests that the CM/HDR metadata needs to live somewhere outside of drm_output base, where you can also do refcounting to cache blobs
<daniels>
rather than moving move dynamic state back into the base struct
nerdopolis has joined #wayland
<pq>
yeah, that is my feeling as well, but blobs don't necessarily need refcounting from the KMS perspective
<pq>
ah, actually HDR_OUTPUT_METADATA is different from the other CM&HDR blobs
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
DEGAMMA, CTM and GAMMA would be cached with a weston_color_transform, so they could be shared by multiple outputs
<pq>
but HDR_OUTPUT_METADATA has no corresponding struct in color manager
<pq>
...yet
<pq>
I haven't designed an API to pass the HDR metadata from color manager to backends yet
<vsyrjala>
not all crtcs might support the same gamma/degamma format
<pq>
sure, that's some DRM-backend can take into account (if KMS just tells us what it supports)
<pq>
maybe I need to design the color manager <-> backend API for HDR metadata first, then it should be easier to see where to store the blob
<pq>
should it be another 1st class object, but OTOH it has some overlap with weston_color_profile
<pq>
no, HDR metadata is an object derived from an output color profile with a chosen EOTF mode.
agd5f_ has quit [Remote host closed the connection]
agd5f has joined #wayland
<pq>
color manager needs to get the output color profile (ICC, EDID, etc.) and from that and chosen EOTF mode it produces HDR metadata object for an output.
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #wayland
<pq>
That still doesn't answer where to store the HDR metadata blobs. They're not big, so de-duplicating them seems unnecessary.
<pq>
but if they're refcounted and have DRM-backend private data...
<pq>
then they'd still be stored in weston_output
<pq>
weston_output -> weston_hdr_metadata -> backend private . blob id
audgirka has quit [Ping timeout: 480 seconds]
audgirka has joined #wayland
<pq>
daniels, does that sound better than drm_output -> blob id?
pi123 has quit [Remote host closed the connection]
silver has joined #wayland
agd5f has quit [Remote host closed the connection]
agd5f has joined #wayland
<daniels>
pq: how big are the blobs?
pi123 has joined #wayland
<pq>
HDR metadata is 30 bytes if I counted right
<pq>
static HDR metadata of type 1, that is, which is all that KMS has atm.
<pq>
CTM isn't big either, but GAMMA and DEGAMMA could be like... 4 or 8 kB at worst I guess
<daniels>
realistically it's all going to round up to a page
<pq>
yup
<daniels>
I wouldn't overthink trying to share it for the sake of saving one page per duplicated output
<pq>
yeah, I'm not trying to share HDR metadata
<daniels>
anyway, sounds like we agree and all good from me, it's definitely another point where we'd need to think about what to do for mode switching (e.g. right now we just exchange half the content of drm_output, throw it at the backend, and hope it succeeds and isn't too destructive ...) but no worse
<pq>
just avoiding to needlessly destroy and re-create blobs
<pq>
changing any of these CM&HDR blobs shouldn't even need a modeset I think
<pq>
but yeah, if you refer to the lack of testing a configuration before actually trying it
<daniels>
indeed
<pq>
DEGAMMA/CTM/GAMMA are not like anything just smashes it in and DRM-backend must make it work at once. These three are optional: GL-renderer can do them if the backend cannot.
<pq>
HDR metadata OTOH is not optional like that.
<pq>
but OTOH, HDR metadata is just data sent to the sink, so I can't see how it could make anything fail in KMS.
<pq>
of course the sink might not handle the metadata we feed it, but there is no way to know that, AFAIU
<pq>
other than open a mic and listen whether there is cursing to be heard
<pq>
Let's see if sleeping over it makes me any wiser. \o.
audgirka has quit [Remote host closed the connection]
<daniels>
'open a mic' :D :D :D
<daniels>
sounds good. I can't say I love the design since it just smashes more dynamic state into drm_output (something which already causes us problems if you look at the comments in switch_mode) but OTOH I can't think of a better one off the top of my head, and like you say it should be harmless in practice
<daniels>
hyvää iltaa
<pq>
hyvää illanjatkoa ;-)
jgrulich has quit [Ping timeout: 480 seconds]
<jadahl>
ei saa peittää
champagneg has joined #wayland
Spathoche has quit [Ping timeout: 480 seconds]
<daniels>
en mä tiedä
tzimmermann has quit [Quit: Leaving]
champagneg has quit []
gchamp has joined #wayland
<LaserEyess>
question about user input, I think curently there's no way for a client to "control" input, even if focused, is that right?
<LaserEyess>
the scenario I'm curious about is for a program called "looking glass", which is for essentially showing guest VMs to the host
<LaserEyess>
and it sometimes allows for the guest cursor and host cursor to get out of focus
Spathoche has joined #wayland
<LaserEyess>
the solution in X is to just detect the host cursor right before it exits the window, find the diffrence between the guest and host cursor, and then warp the host cursor to where the guest cursor would be at the edge
<LaserEyess>
so when you exit the window and switch to the host cursor, you're not confused by the diferene in where the guest cursor stops and the host cursor exits
<LaserEyess>
so, basically, is there any functionality for a client to move a cursor when focused?
<dottedmag>
There's zwlr_virtual_pointer in wlroots and org_kde_kwin_fake_input in KWin. Obviously, they are per-compositor (family), and I'm not sure they are not restricted to privileged clients.
<LaserEyess>
not quite sure I follow here, wlr_virtual_pointer says it's the opposite of wl_pointer, but in what way
<LaserEyess>
does this mean literal, as in the client is telling the compositor about pointer movement?
valentind has quit [Read error: No route to host]
valentind has joined #wayland
quantum5 has quit [Remote host closed the connection]
quantum5 has joined #wayland
remanifest has joined #wayland
<remanifest>
Hey everybody, I'm using KDE 5.22 with Wayland and SDDM. When I choose Switch User from the KDE menu, I'm not able to switch users; I can only unlock the account that I was just using, and the graphics on the display flicker. If I log out, this behavior doesn't happen. Any ideas on what I can do?
<dottedmag>
LaserEyess: Looks so, though I have never used them TBH
<ifreund>
remanifest: that's really a question for kde channels
<daniels>
LaserEyess: I think what you want is the pointer-lock protocol then to draw your own cursor
<remanifest>
ifreund: Got it - that's where I went first. I was waiting for a response there. I'll keep waiting. Thanks!
<LaserEyess>
daniels: yes I think this is actually exactly what I'm looking for, thank you!
SallyAhaj has quit [Ping timeout: 480 seconds]
<daniels>
LaserEyess: happy to help :)
<LaserEyess>
someone also thought of a fun hack for emulating cursor warp in xorg, setting a 1x1 constrained area
<LaserEyess>
curious to see how it will work lol
Spathoche has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
immibis is now known as Guest802
immibis has joined #wayland
Guest802 has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
d42 has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
zebrag_ has joined #wayland
zebrag has quit [Ping timeout: 480 seconds]
silver has joined #wayland
leon-p has quit [Quit: leaving]
danvet has quit [Ping timeout: 480 seconds]
bluebugs has quit [Quit: Leaving]
pnowack has quit [Quit: pnowack]
nerdopolis has joined #wayland
zebrag_ has quit []
zebrag has joined #wayland
immibis is now known as Guest825
immibis has joined #wayland
Guest825 has quit [Ping timeout: 480 seconds]
remanifest has quit [Remote host closed the connection]