using libinput with glib's signal_timeout
Hey Guys, currently I'm trying to use a libinput's eventloop. It used to work as a standalone, but when I tried to put it into Glib::signal_timeout it seems to not receive any events anymore. Do you know more about why this is happening? I put a simple example of what I mean in the attachment. Greetings Kyomawolf sample.tar.gz Description: application/gzip
Steam Deck integrated display: saturation boosting or reduction?
This is a continuation of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_2152254 because this is off-topic in that thread. > No, we did widening. The Deck's internal display has a modest gamut > that is < 71% sRGB. If games do wide (well, full sRGB or wider) gamut, then why would you need to make that gamut even wider to fit nicely into a significantly smaller gamut display? Here's what I think happened. You have a game that produces saturation up to P3, let's say. When you did the colorimetrically correct matrix conversion (CTM) from BT.2020 to the "modest gamut", you found out that it is horribly clipping colors, right? If you then removed that CTM, it means that you are re-interpreting BT.2020 RGB encoding *as if* it was "modest gamut" RGB encoding. This happens if you simply apply the input image EOTF and then apply the display inverse-EOTF and do nothing to the color gamut in between. Adjusting dynamic range does not count here. This is an extreme case of saturation reduction. (Note: Doing nothing to numbers equals to applying a major semantic operation. Like telling someone something in cm and they take that number in mm instead. Or metric vs. imperial units. Color space primaries and white point define the units for RGB values, and if you have other RGB values, they are not comparable without the proper CTM conversion.) That does not look good either, so after that re-interpretation you added saturation boosting that nicely makes use of the capabilities of the integrated display's "modest gamut" so that the image looks more "vibrant" and less de-saturated. However, the total effect is still saturation reduction, because the re-interpretation of the game content RGB values is such a massive saturation reduction that your boosting does not overcome it. I could make up an analogue: Someone says they are making all sticks 50% longer than what you ask. You ask them to make a stick 100 long. They give you a stick that you measure to be 15 long, and they still claim it is 50% longer than what you asked. How is this possible? The length spaces are different: you were thinking and measuring in cm, they did mm. They did give you a stick of 150 mm, which is 50% longer than 100 mm. But from your perspective, the stick is 85% smaller than you asked. If one had started by converting to a mutual length space first (referring to the correct CTM), there would be an initial agreement of how long is 1. Thanks, pq pgp8icu9jG5jk.pgp Description: OpenPGP digital signature
Exploring the Need for a Standardized Window Management API within or alongside Wayland
Is a unified approach for window management in the Wayland ecosystem needed? (i.e how can the end user or system designer control the size, position, and layer of top level application windows). Wayland's design emphasizes security, simplicity, and a clear separation of responsibilities between the compositor and client applications. This has no doubt paved the way for a more secure and stable desktop environment. Yet, as users and developers navigate this shift, especially those handling applications with specific window management needs, they face challenges due to the absence of standardized control over window size and position within the current protocol. Acknowledging these challenges, I would like to initiate a conversation around the potential benefits and feasibility of introducing a standardized API or protocol, which could be designed as an intrinsic part of Wayland or as an independent, interoperable specification running alongside it. This is crucial for those transitioning from X11 to Wayland, where the ability to directly manage window properties is an essential feature. Certain applications and workflows, particularly those involving complex window arrangements, dynamic window resizing, and precise positioning (e.g., tiling window managers, graphical editing tools, and presentation software), can greatly benefit from having a measure of control over their window geometry and stacking. Currently, attempts at providing this are being done by a variety of compositor-specific protocols and extensions, which can lead to fragmentation and inconsistent user and developer experiences across different environments. A standard API or protocol would only serve the needs of these applications and would also aim to prevent the proliferation of inconsistent and ad hoc solutions. Some goals of a standardized approach: - Maintain the security and stability principles of Wayland. - Allow applications with legitimate needs to manage their window geometry in a way that is consistent across different compositors. - Provide a clear and unified direction for developers, which could encourage wider adoption and smoother transitions from other systems to Wayland.
Re: Exploring the Need for a Standardized Window Management API within or alongside Wayland
On Fri, Nov 3, 2023 at 9:33 AM Wayne Sherman wrote: > Certain applications and workflows...can greatly benefit from having > a measure of control over their window geometry and stacking. There are many use cases for this. A few of mine are: Digital Signage Video outputs on the digital signage "player" computer feed one or more LED sign controllers and need to be set to specific video modes (resolution, refresh rate, color depth, etc). Digital signage "player" applications have top level windows that need to be placed on specific video outputs and sized and positioned at specific screen pixel coordinates for the LED signs to display properly. (LCD digital signage has similar requirements) Simple VLC Security Camera Viewer I want to create a script or simple application that launches 6 VLC instances which stream video from 6 network connected cameras. Each VLC application window has to be sized and positioned to a specific area of the screen. Desktop Application Automation I use a 6-button Stream Deck keypad to automate various tasks. One of my buttons is programmed to activate my Google Meet video conference window (i.e. bring it to the front and put focus on it). I currently do this with the X based xdotool utility: xdotool search --name '^Meet - .+$' windowactivate
