Yeah, I believe both of these should be covered by input-method. The input-method protocol can grab the keyboard (getting all input events) and pass UTF-8 strings to applications.
Sounds to me like the existing input-method protocol may be sufficient for this use-case?
Disclaimer, I am not familiar with stenography.
Simon Ser (cd23d17a) at 27 Mar 19:03
Simon Ser (cd23d17a) at 27 Mar 19:03
Add support for lutAToB and lutBToA
/usr/share/color/icc/colord/x11-colors.icc
fails (Crayons
as well)Closes: #177 Signed-off-by: Sebastian Wick sebastian.wick@redhat.com
Simon Ser (1c57b24f) at 27 Mar 18:17
xdg-shell: add missing enum attribute to set_constraint_adjustment
Noticed this since I had to do a raw conversion in wayland-rs.
Simon Ser (1c57b24f) at 27 Mar 18:15
xdg-shell: add missing enum attribute to set_constraint_adjustment
... and 7 more commits
And yeah, hashing the whole EDID would definitely work for my purposes. I see in your comments you linked you say that some compositors already do this. Since the linked thread is pretty old, I have to ask, is there any particular reason why it hasn't been added to wlroots? Could it possibly be considered too opinionated?
Mostly, hashing isn't what people want in general. In general, people want to identify a particular screen regardless of its own settings (in your case, regardless of whether or not game mode is enabled, for instance).
I don't really know of any way to change the mode on this monitor outside of using the remote
I'd expect HDMI InfoFrames to control this. Maybe the "content type" KMS property? Maybe some other InfoFrame field not yet exposed by KMS?
If I understand correctly, exposing the product code like this might be a bit hacky? On the flip side I don't really see why wlroots wouldn't want to expose all parsed EDID fields to compositors? Feel free to link me to prior discussion if I've just overlooked it.
Because there are a lot of EDID fields, because maybe there is a DisplayID which has priority, maybe there is no EDID at all. Hence my earlier question about exposing the libdisplay-info struct.
Simon Ser (f5d63fad) at 27 Mar 16:53
Add struct icc_multi_process_transform_priv
About
wlr_drm_connector_get_id()
, that looks interesting. Is that something that I could make Hyprland use to expose the product code? Can't really comment on it myself. I've really only delved as deep as I've needed to to make this change on my own copy of Hyprland. Completely unfamiliar with the wlroots codebase otherwise :)
Yeah, to do so you'd need to use wlr_backend_get_drm_fd()
to get the DRM FD, wlr_drm_connector_get_id()
to get the connector object ID, drmModeObjectGetProperties()
to list connector properties, drmModeGetProperty()
to find the "EDID" property, and drmModeGetPropertyBlob()
to fetch the EDID bytes.
Oh, then I misunderstood your use-case. I thought you wanted to tell apart two screens, but it seems like you want to check if a single screen has game mode enabled?
For the purpose of checking if screen settings changed, hashing the whole EDID seems like a more reliable way. It surprises me that the product code change when game mode is enabled (I believe that's pretty much specific to your screen). Although only few screens re-generate their EDID when the settings are changed (most screens have a fixed, static EDID which never changes).
Simon Ser (dda2a022) at 27 Mar 15:54
tool: add input file argument and help flag
Simon Ser (0d380e35) at 27 Mar 15:39
Add support for lutAToB and lutBToA
Simon Ser (8673c92b) at 27 Mar 15:10