Re: Weston window move to second monitor
On Sun, Oct 02, 2022 at 09:13:27AM +0100, Terry Barnaby wrote: > Hi, > > I am developing software for an instrument embedded system using NXP CPU's > and the Wayland/Weston GUI system. > > The hardware platform has a main LCD panel and an optional plug-in HDMI > monitor. The GUI is currently running with the Weston kiosk-shell and a > single application is shown full screen on the LCD. Weston is configured so > that the HDMI monitor appears to the right of the LCD screen and if the > desktop-shell is used applications can be dragged across. > > Now what I would like is for the application to be moved to the HDMI > monitor/screen when the monitor is plugged in (resizing as needed). > > With X11 I would have simply, from the application, moved its top level > window coordinates and without a window manager or with a simple window > manager the window would move to the area of the second screen. > > Now I understand that Weston and the standard Wayland protocol's do not even > allow a window move request to be made. > > So I assume I might have to implement a whole new Weston shell, perhaps > based on the kiosk-shell, and either invent some form of protocol to allow > the application to request the shell to move it or get the shell to see HDMI > plug in events and move the application and tell it to resize. > > I don't have much knowledge of Wayland/Weston internals (lots of X11), so > can anyone give me any pointers on how I might achieve this in the > simplest/quickest way ? > > Terry Hi Terry, Assuming you only care about the fullscreen case, an application can request (but not force) a fullscreen placement for a toplevel surface with: xdg_toplevel_set_fullscreen(xdg_toplevel, wl_output) In your application you could listen for advertised wl_output globals and issue a set_fullscreen request for the preferred wl_output (e.g., based on the wl_output/xdg_output name). Since you are only dealing with a specific compositor under your control, you can be fairly confident that you will get consistent behavior here, i.e., the compositor will honor your request. Note that kiosk-shell provides a mechanism in the .ini file to declare the placement of applications on specific outputs. However, the output placement decision is static, made only when the surface is first created/committed to, not for any subsequent output reconfigurations. Making this output placement in kiosk-shell work more dynamically (optionally), with the shell moving the surface to the preferred output, could possibly be a useful enhancement for some use cases. HTH, Alexandros
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Fri, 30 Sep 2022 18:17:39 +0200 Sebastian Wick wrote: > On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen wrote: > > > > On Fri, 30 Sep 2022 17:44:17 +0300 > > Ville Syrjälä wrote: > > > > > On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote: > > > > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen > > > > wrote: > > > > > > > > > > On Thu, 29 Sep 2022 20:06:50 +0200 > > > > > Sebastian Wick wrote: > > > > > > > > > > > If it is supposed to be a non-linear luminance curve, which one is > > > > > > it? > > > > > > It would be much clearer if user space can control linear luminance > > > > > > and use whatever definition of perceived brightness it wants. The > > > > > > obvious downside of it is that it requires bits to encode changes > > > > > > that > > > > > > users can't perceive. What about backlights which only have a few > > > > > > predefined luminance levels? How would user space differentiate > > > > > > between the continuous and discrete backlight? What about > > > > > > self-emitting displays? They usually increase the dynamic range when > > > > > > they increase in brightness because the black level doesn't rise. > > > > > > They > > > > > > also probably employ some tonemapping to adjust for that. What about > > > > > > the range of the backlight? What about the absolute luminance of the > > > > > > backlight? I want to know about that all in user space. > > > > > > > > > > > > I understand that most of the time the kernel doesn't have answers > > > > > > to > > > > > > those questions right now but the API should account for all of > > > > > > that. ... > > I'm saying that what looks realistic to me is somewhere *between* > > status quo and what Sebastian is asking for. Whatever you mean by "linear > > remapping" is probably a realistic goal, because you know you have some > > hardware/firmware delivering that information already. > > > > OTOH, designing UAPI for information that exists only in our dreams > > is... well. > > I also didn't say that we should design an UAPI for what doesn't > exist, just that we should design the UAPI we actually need in a way > that when we get more information we can properly expose that. So if > the UAPI exposes anything other than the luminance (e.g. "each step is > a perceptual step in brightness", "linear brightness", ..) we have to > put some human perception model into the kernel which is ridiculous > and it makes it impossible to expose luminance to user space if the > kernel has that information. You don't need a human perception model in the kernel. You also cannot have one, because I would expect most or all backlight and their metadata to not define luminance at all. But that is just a guess. I suppose the firmware may expose some tables that may allow mapping raw hardware values into something more pleasant to use. Like something where each step is more or less a visible change. That does not have to imply anything about linearity in any space, they may just be "good values" for e.g. keyboard-based changing of backlight levels with no mathematical or physical basis. Ville, what kind of tables do you know about? What do they actually tell? Let's say we have these first properties defined as "reasonable steps for manual backlight control": one integer for the value, another integer for the max. If we later see that we can actually get more precise or high-level information, we can add new optional properties, e.g. a blob with table that maps the integers into some better defined quantity. Then we know what the values mean, but the steps may be quite coarse, much coarser than what the raw control value allows. That's the next problem: if we want as fine control as hardware is capable, how do you expose that? Should the answer be, that the exposed integer is actually a raw value for hardware, merely offsetted so that zero maps to minimum but visible backlight level, and then add another property from the start with a table for the "good values" for keyboard control? And the "good values" would be literally just that, no implication of linearity of anything. Thanks, pq pgpcETJQxofeS.pgp Description: OpenPGP digital signature
Re: KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)
On Fri, 30 Sep 2022 18:45:09 +0300 Ville Syrjälä wrote: > On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote: > > On Fri, 30 Sep 2022 18:09:55 +0300 > > Ville Syrjälä wrote: > > > > > That would actively discourage people from even attempting the > > > "just dump all the state into the ioctl" approach with async flips > > > since even the props whose value isn't even changing would be rejected. > > > > About that. > > > > To me it looks like just a classic case of broken communication. > > > > The kernel developers assume that of course userspace will minimize the > > state set to only those properties that change, because...? > > > > Userspace developers think that of course the kernel will optimize the > > state set into minimal changes, because the kernel actually has the > > authoritative knowledge of what the current state is, and the driver > > actually knows which properties are costly and need to be optimized and > > which ones don't matter. It has never even occurred to me that the > > kernel would not compare next state to current state. > > > > No-one ever documented any expectations, did they? > > Do you really want that for async flips? Async flips can't be > done atomically with anything else, so why are you even asking > the kernel to do that? I'm not talking about async flips only. I'm talking about atomic commits in general. I don't think it's a good idea to make async atomic commits behave fundamentally different from sync atomic commits wrt. what non-changing state you are allowed to list in your state set or not. Isn't there common DRM code to convert an atomic commit state set into state objects? It probably starts by copying the current state, and then playing through the commit state set, setting all listed properties to their new values? Why wouldn't that loop maintain the knowledge of what actually changed? When you copy the current data, reset all changed-flags to false. When you apply each property from the commit set, compare the value and set the changed-flag only if the value changes. This manufacturing of the new tentative state set happens at atomic commit ioctl time before the ioctl returns, right? So the current state is well-defined: any previous atomic sync or async commit can be assumed to have succeeded even if it hasn't applied in hardware yet if the commit ioctl for it succeeded, right? Thanks, pq pgpT_JOQuORSZ.pgp Description: OpenPGP digital signature
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
Hi, On 9/28/22 12:04, Jani Nikula wrote: > On Fri, 09 Sep 2022, Hans de Goede wrote: >> Hi all, >> >> Here is v2 of my "drm/kms: control display brightness through drm_connector >> properties" RFC: >> >> Changes from version 1: >> - Drop bl_brightness_0_is_min_brightness from list of new connector >> properties. >> - Clearly define that 0 is always min-brightness when setting the brightness >> through the connector properties. >> - Drop bl_brightness_control_method from list of new connector >> properties. >> - Phase 1 of the plan has been completed >> >> As discussed already several times in the past: >> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ >> >> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ >> >> The current userspace API for brightness control offered by >> /sys/class/backlight devices has various issues: >> >> 1. There is no way to map the backlight device to a specific >>display-output / panel (1) >> 2. Controlling the brightness requires root-rights requiring >>desktop-environments to use suid-root helpers for this. >> 3. The meaning of 0 is not clearly defined, it can be either off, >>or minimum brightness at which the display is still readable >>(in a low light environment) >> 4. It's not possible to change both the gamma and the brightness in the >>same KMS atomic commit. You'd want to be able to reduce brightness to >>conserve power, and counter the effects of that by changing gamma to >>reach a visually similar image. And you'd want to have the changes take >>effect at the same time instead of reducing brightness at some frame and >>change gamma at some other frame. This is pretty much impossible to do >>via the sysfs interface. >> >> As already discussed on various conference's hallway tracks >> and as has been proposed on the dri-devel list once before (2), >> it seems that there is consensus that the best way to to solve these >> 2 issues is to add support for controlling a video-output's brightness >> through properties on the drm_connector. >> >> This RFC outlines my plan to try and actually implement this, >> which has 3 phases: >> >> >> Phase 1: Stop registering multiple /sys/class/backlight devs for a single >> display >> = >> >> On x86 there can be multiple firmware + direct-hw-access methods >> for controlling the backlight and in some cases the kernel registers >> multiple backlight-devices for a single internal laptop LCD panel. >> >> A plan to fix this was posted here: >> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ >> And a pull-req actually implementing this plan has been send out this week: >> https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/ >> >> >> Phase 2: Add drm_connector properties mirroring the matching backlight device >> = >> >> The plan is to add a drm_connector helper function, which optionally takes >> a pointer to the backlight device for the GPU's native backlight device, >> which will then mirror the backlight settings from the backlight device >> in a set of read/write brightness* properties on the connector. >> >> This function can then be called by GPU drivers for the drm_connector for >> the internal panel and it will then take care of everything. When there >> is no native GPU backlight device, or when it should not be used then >> (on x86) the helper will use the acpi_video_get_backlight_type() to >> determine which backlight-device should be used instead and it will find >> + mirror that one. >> >> >> Phase 3: Deprecate /sys/class/backlight uAPI >> >> >> Once most userspace has moved over to using the new drm_connector >> brightness props, a Kconfig option can be added to stop exporting >> the backlight-devices under /sys/class/backlight. The plan is to >> just disable the sysfs interface and keep the existing backlight-device >> internal kernel abstraction as is, since some abstraction for (non GPU >> native) backlight devices will be necessary regardless. >> >> It is unsure if we will ever be able to do this. For example people using >> non fully integrated desktop environments like e.g. sway often use custom >> scripts binded to hotkeys to get functionality like the brightness >> up/down keyboard hotkeys changing the brightness. This typically involves >> e.g. the xbacklight utility. >> >> Even if the xbacklight utility is ported to use kms with the new connector >> object brightness properties then this still will not work because >> changing the properties will require drm-master rights and e.g. sway will >> already hold those. >> >> >> The drm_connector brightness properties >> === >> >> The new uAPI for this consists of 2 properties: >>
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
Hi, On 9/28/22 12:57, Ville Syrjälä wrote: > On Wed, Sep 28, 2022 at 01:04:01PM +0300, Jani Nikula wrote: >> On Fri, 09 Sep 2022, Hans de Goede wrote: >>> Hi all, >>> >>> Here is v2 of my "drm/kms: control display brightness through drm_connector >>> properties" RFC: >>> >>> Changes from version 1: >>> - Drop bl_brightness_0_is_min_brightness from list of new connector >>> properties. >>> - Clearly define that 0 is always min-brightness when setting the brightness >>> through the connector properties. >>> - Drop bl_brightness_control_method from list of new connector >>> properties. >>> - Phase 1 of the plan has been completed >>> >>> As discussed already several times in the past: >>> https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/ >>> >>> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/ >>> >>> The current userspace API for brightness control offered by >>> /sys/class/backlight devices has various issues: >>> >>> 1. There is no way to map the backlight device to a specific >>>display-output / panel (1) >>> 2. Controlling the brightness requires root-rights requiring >>>desktop-environments to use suid-root helpers for this. >>> 3. The meaning of 0 is not clearly defined, it can be either off, >>>or minimum brightness at which the display is still readable >>>(in a low light environment) >>> 4. It's not possible to change both the gamma and the brightness in the >>>same KMS atomic commit. You'd want to be able to reduce brightness to >>>conserve power, and counter the effects of that by changing gamma to >>>reach a visually similar image. And you'd want to have the changes take >>>effect at the same time instead of reducing brightness at some frame and >>>change gamma at some other frame. This is pretty much impossible to do >>>via the sysfs interface. >>> >>> As already discussed on various conference's hallway tracks >>> and as has been proposed on the dri-devel list once before (2), >>> it seems that there is consensus that the best way to to solve these >>> 2 issues is to add support for controlling a video-output's brightness >>> through properties on the drm_connector. >>> >>> This RFC outlines my plan to try and actually implement this, >>> which has 3 phases: >>> >>> >>> Phase 1: Stop registering multiple /sys/class/backlight devs for a single >>> display >>> = >>> >>> On x86 there can be multiple firmware + direct-hw-access methods >>> for controlling the backlight and in some cases the kernel registers >>> multiple backlight-devices for a single internal laptop LCD panel. >>> >>> A plan to fix this was posted here: >>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ >>> And a pull-req actually implementing this plan has been send out this week: >>> https://lore.kernel.org/dri-devel/261afe3d-7790-e945-adf6-a2c96c9b1...@redhat.com/ >>> >>> >>> Phase 2: Add drm_connector properties mirroring the matching backlight >>> device >>> = >>> >>> The plan is to add a drm_connector helper function, which optionally takes >>> a pointer to the backlight device for the GPU's native backlight device, >>> which will then mirror the backlight settings from the backlight device >>> in a set of read/write brightness* properties on the connector. >>> >>> This function can then be called by GPU drivers for the drm_connector for >>> the internal panel and it will then take care of everything. When there >>> is no native GPU backlight device, or when it should not be used then >>> (on x86) the helper will use the acpi_video_get_backlight_type() to >>> determine which backlight-device should be used instead and it will find >>> + mirror that one. >>> >>> >>> Phase 3: Deprecate /sys/class/backlight uAPI >>> >>> >>> Once most userspace has moved over to using the new drm_connector >>> brightness props, a Kconfig option can be added to stop exporting >>> the backlight-devices under /sys/class/backlight. The plan is to >>> just disable the sysfs interface and keep the existing backlight-device >>> internal kernel abstraction as is, since some abstraction for (non GPU >>> native) backlight devices will be necessary regardless. >>> >>> It is unsure if we will ever be able to do this. For example people using >>> non fully integrated desktop environments like e.g. sway often use custom >>> scripts binded to hotkeys to get functionality like the brightness >>> up/down keyboard hotkeys changing the brightness. This typically involves >>> e.g. the xbacklight utility. >>> >>> Even if the xbacklight utility is ported to use kms with the new connector >>> object brightness properties then this still will not work because >>> changing the properties will require drm-master rights and e.g. sway will >>> a
Re: KMS atomic state sets, full vs. minimal (Re: [PATCH v3 0/6] Add support for atomic async page-flips)
On Mon, Oct 03, 2022 at 11:48:49AM +0300, Pekka Paalanen wrote: > On Fri, 30 Sep 2022 18:45:09 +0300 > Ville Syrjälä wrote: > > > On Fri, Sep 30, 2022 at 06:37:00PM +0300, Pekka Paalanen wrote: > > > On Fri, 30 Sep 2022 18:09:55 +0300 > > > Ville Syrjälä wrote: > > > > > > > That would actively discourage people from even attempting the > > > > "just dump all the state into the ioctl" approach with async flips > > > > since even the props whose value isn't even changing would be rejected. > > > > > > > > > > About that. > > > > > > To me it looks like just a classic case of broken communication. > > > > > > The kernel developers assume that of course userspace will minimize the > > > state set to only those properties that change, because...? > > > > > > Userspace developers think that of course the kernel will optimize the > > > state set into minimal changes, because the kernel actually has the > > > authoritative knowledge of what the current state is, and the driver > > > actually knows which properties are costly and need to be optimized and > > > which ones don't matter. It has never even occurred to me that the > > > kernel would not compare next state to current state. > > > > > > No-one ever documented any expectations, did they? > > > > Do you really want that for async flips? Async flips can't be > > done atomically with anything else, so why are you even asking > > the kernel to do that? > > I'm not talking about async flips only. > > I'm talking about atomic commits in general. I don't think it's a good > idea to make async atomic commits behave fundamentally different from > sync atomic commits wrt. what non-changing state you are allowed to > list in your state set or not. > > Isn't there common DRM code to convert an atomic commit state set into > state objects? It probably starts by copying the current state, and > then playing through the commit state set, setting all listed > properties to their new values? Why wouldn't that loop maintain the > knowledge of what actually changed? Any such book keeping is entirely ad-hoc atm. It's also not super obvious how much of it is actually useful. You have to do a real commit on the crtc anyway if the crtc (or on any of its associated objects) is listed in the commit, so there's not necessarily much to be gained by tracking chages in all properties. And that behaviour again enters very muddy waters when combined with the async flip flag for the entire commit. The current approach being proposed seems to suggest that we can instead short circuit async commits when nothing has changed. That is not at all how sync atomic commits work. > When you copy the current data, reset all changed-flags to false. When > you apply each property from the commit set, compare the value and set > the changed-flag only if the value changes. > > This manufacturing of the new tentative state set happens at atomic > commit ioctl time before the ioctl returns, right? So the current state > is well-defined: any previous atomic sync or async commit can be assumed to > have succeeded even if it hasn't applied in hardware yet if the commit > ioctl for it succeeded, right? Yes. We could certainly try to fully track all changes in properties, but no has measured if there's any real benefit of doing so. -- Ville Syrjälä Intel
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Mon, Oct 03, 2022 at 11:37:50AM +0300, Pekka Paalanen wrote: > On Fri, 30 Sep 2022 18:17:39 +0200 > Sebastian Wick wrote: > > > On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen wrote: > > > > > > On Fri, 30 Sep 2022 17:44:17 +0300 > > > Ville Syrjälä wrote: > > > > > > > On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote: > > > > > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen > > > > > wrote: > > > > > > > > > > > > On Thu, 29 Sep 2022 20:06:50 +0200 > > > > > > Sebastian Wick wrote: > > > > > > > > > > > > > If it is supposed to be a non-linear luminance curve, which one > > > > > > > is it? > > > > > > > It would be much clearer if user space can control linear > > > > > > > luminance > > > > > > > and use whatever definition of perceived brightness it wants. The > > > > > > > obvious downside of it is that it requires bits to encode changes > > > > > > > that > > > > > > > users can't perceive. What about backlights which only have a few > > > > > > > predefined luminance levels? How would user space differentiate > > > > > > > between the continuous and discrete backlight? What about > > > > > > > self-emitting displays? They usually increase the dynamic range > > > > > > > when > > > > > > > they increase in brightness because the black level doesn't rise. > > > > > > > They > > > > > > > also probably employ some tonemapping to adjust for that. What > > > > > > > about > > > > > > > the range of the backlight? What about the absolute luminance of > > > > > > > the > > > > > > > backlight? I want to know about that all in user space. > > > > > > > > > > > > > > I understand that most of the time the kernel doesn't have > > > > > > > answers to > > > > > > > those questions right now but the API should account for all of > > > > > > > that. > > ... > > > > I'm saying that what looks realistic to me is somewhere *between* > > > status quo and what Sebastian is asking for. Whatever you mean by "linear > > > remapping" is probably a realistic goal, because you know you have some > > > hardware/firmware delivering that information already. > > > > > > OTOH, designing UAPI for information that exists only in our dreams > > > is... well. > > > > I also didn't say that we should design an UAPI for what doesn't > > exist, just that we should design the UAPI we actually need in a way > > that when we get more information we can properly expose that. So if > > the UAPI exposes anything other than the luminance (e.g. "each step is > > a perceptual step in brightness", "linear brightness", ..) we have to > > put some human perception model into the kernel which is ridiculous > > and it makes it impossible to expose luminance to user space if the > > kernel has that information. > > You don't need a human perception model in the kernel. You also cannot > have one, because I would expect most or all backlight and their > metadata to not define luminance at all. But that is just a guess. > > I suppose the firmware may expose some tables that may allow mapping > raw hardware values into something more pleasant to use. Like something > where each step is more or less a visible change. That does not have to > imply anything about linearity in any space, they may just be "good > values" for e.g. keyboard-based changing of backlight levels with no > mathematical or physical basis. > > Ville, what kind of tables do you know about? What do they actually > tell? We just get a set of points (up to 20 originally, and I think up to 32 in later spec revisions) that map input brightness (in %) to output duty cycle (0-0xff in old spec, 0-0x in new spec). And I *think* we're supposed to just linearly inteprolate between the entries, though the spec doesn't really state that in super clear terms. There is some mention in the spec about this being more or less designed for Windows Vista, so a look through eg. https://learn.microsoft.com/en-us/windows-hardware/drivers/display/supporting-brightness-controls-on-integrated-display-panels might be a good idea here. -- Ville Syrjälä Intel
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
Hi, On 9/30/22 18:17, Sebastian Wick wrote: > On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen wrote: >> >> On Fri, 30 Sep 2022 17:44:17 +0300 >> Ville Syrjälä wrote: >> >>> On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote: On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen wrote: > > On Thu, 29 Sep 2022 20:06:50 +0200 > Sebastian Wick wrote: > >> If it is supposed to be a non-linear luminance curve, which one is it? >> It would be much clearer if user space can control linear luminance >> and use whatever definition of perceived brightness it wants. The >> obvious downside of it is that it requires bits to encode changes that >> users can't perceive. What about backlights which only have a few >> predefined luminance levels? How would user space differentiate >> between the continuous and discrete backlight? What about >> self-emitting displays? They usually increase the dynamic range when >> they increase in brightness because the black level doesn't rise. They >> also probably employ some tonemapping to adjust for that. What about >> the range of the backlight? What about the absolute luminance of the >> backlight? I want to know about that all in user space. >> >> I understand that most of the time the kernel doesn't have answers to >> those questions right now but the API should account for all of that. > > Hi, > > if the API accounts for all that, and the kernel doesn't know, then how > can the API not lie? If the API sometimes lies, how could we ever trust > it at all? Make it possible for the API to say "I don't know". I'd much rather have an API tell me explicitly what it does and doesn't know instead of having to guess what data I can actually rely on. For example if the kernel knows the luminance is linear on one display and doesn't know anything about the other display and it exposes them both in the same way I can not possibly write any code which relies on exact control over the luminance for either display. > > Personally I have the feeling that if we can even get to the level of > "each step in the value is a more or less perceivable change", that > would be good enough. Think of UI, e.g. hotkeys to change brightness. > You'd expect almost every press to change it a bit. The nice thing is that you can have that even if you have no further information about the brightness control and it might be good enough for some use cases but it isn't for others. > If an end user wants defined and controlled luminance, I'd suggest they > need to profile (physically measure) the response of the display at > hand. This is no different from color profiling displays, but you need > a measurement device that produces absolute measurements if absolute > control is what they want. If that's the kind of user experience you're after, good for you. I certainly want things to work out of the box which makes this just a big no-go. >>> >>> I think if we have the information to make the default behaviour >>> better then we should do that. Ie. if the firmaware gives us a >>> table to remap the values for a more linear response we should >>> make use of that by default. >> >> But that's only like 20% of what Sebastian is asking for. >> >> What's "linear"? Radiometric or perceptual? >> >> Radiometric linear control would make a terrible UX, so if the control >> is radiometric, userspace needs to remap it. That might be a good >> thing, but it's also complicated, because the relationship between >> brightness and luminance is somewhere between a power curve and >> exponential curve. You need to make sure that the userspace remapping >> works for different backlights with different luminance ranges. That's >> not obvious to me. >> >>> We can of course provide a way for the user to plug in their own >>> actually measured data later. But IMO that doesn't even have to >>> happen in the initial implementation. Just need to avoid painting >>> ourselves totally in the corner in a way that would prevent later >>> additions like that. >> >> For userspace delivering its own curve, you need to define the units. >> Absolute or relative? Radiometric or perceptual? Otherwise the >> resulting control is not portable between window systems. >> >>> I just hate the current limbo where we're somehow too afraid to >>> change the current behaviour to do the remapping by default. >>> I see no upsides in the current behaviour of just blindly >>> exposing the raw hardware register values more or less. They >>> mean absolutely nothing to any user. >> >> I never argued like that. >> >> I'm saying that what looks realistic to me is somewhere *between* >> status quo and what Sebastian is asking for. Whatever you mean by "linear >> remapping" is probably a realistic goal, because you know you have some
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Mon, 3 Oct 2022 12:29:01 +0300 Ville Syrjälä wrote: > On Mon, Oct 03, 2022 at 11:37:50AM +0300, Pekka Paalanen wrote: > > On Fri, 30 Sep 2022 18:17:39 +0200 > > Sebastian Wick wrote: > > > > > On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen > > > wrote: > > > > > > > > On Fri, 30 Sep 2022 17:44:17 +0300 > > > > Ville Syrjälä wrote: > > > > > > > > > On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote: > > > > > > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen > > > > > > wrote: > > > > > > > > > > > > > > On Thu, 29 Sep 2022 20:06:50 +0200 > > > > > > > Sebastian Wick wrote: > > > > > > > > > > > > > > > If it is supposed to be a non-linear luminance curve, which one > > > > > > > > is it? > > > > > > > > It would be much clearer if user space can control linear > > > > > > > > luminance > > > > > > > > and use whatever definition of perceived brightness it wants. > > > > > > > > The > > > > > > > > obvious downside of it is that it requires bits to encode > > > > > > > > changes that > > > > > > > > users can't perceive. What about backlights which only have a > > > > > > > > few > > > > > > > > predefined luminance levels? How would user space differentiate > > > > > > > > between the continuous and discrete backlight? What about > > > > > > > > self-emitting displays? They usually increase the dynamic range > > > > > > > > when > > > > > > > > they increase in brightness because the black level doesn't > > > > > > > > rise. They > > > > > > > > also probably employ some tonemapping to adjust for that. What > > > > > > > > about > > > > > > > > the range of the backlight? What about the absolute luminance > > > > > > > > of the > > > > > > > > backlight? I want to know about that all in user space. > > > > > > > > > > > > > > > > I understand that most of the time the kernel doesn't have > > > > > > > > answers to > > > > > > > > those questions right now but the API should account for all of > > > > > > > > that. ... > > I suppose the firmware may expose some tables that may allow mapping > > raw hardware values into something more pleasant to use. Like something > > where each step is more or less a visible change. That does not have to > > imply anything about linearity in any space, they may just be "good > > values" for e.g. keyboard-based changing of backlight levels with no > > mathematical or physical basis. > > > > Ville, what kind of tables do you know about? What do they actually > > tell? > > We just get a set of points (up to 20 originally, and I think up to > 32 in later spec revisions) that map input brightness (in %) to > output duty cycle (0-0xff in old spec, 0-0x in new spec). > And I *think* we're supposed to just linearly inteprolate between > the entries, though the spec doesn't really state that in super > clear terms. > > There is some mention in the spec about this being more or less > designed for Windows Vista, so a look through eg. > https://learn.microsoft.com/en-us/windows-hardware/drivers/display/supporting-brightness-controls-on-integrated-display-panels > might be a good idea here. That's a nice link. Quote: "Brightness levels are represented as single-byte values in the range from zero to 100 where zero is off and 100 is the maximum brightness that a laptop computer supports. Every laptop computer must report a maximum brightness level of 100; however, a laptop computer is not required to support a level of zero. The only requirement for values from zero to 100 is that larger values must represent higher brightness levels. The increment between levels is not required to be uniform, and a laptop computer can support any number of distinct values up to the maximum of 101 levels. You must decide how to map hardware levels to the range of brightness level values. However, a call to the display miniport driver's DxgkDdiGetPossibleBrightness function should not report more brightness level values than the hardware supports." Sounds like "good values" to me, and that each value must be distinguishable from any another (at least electrically). Thanks, pq pgp4pfmyVC2XC.pgp Description: OpenPGP digital signature
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
On Mon, 3 Oct 2022 11:44:56 +0200 Hans de Goede wrote: > One example mentioned here is that laptops with Intel integrated > graphics may have some "perceived brightness" mapping table > in their Video BIOS Tables (VBT) it would be interesting to use > this and to export the curve coming from that to userspace as > extra information (including allow userspace to write it). > Since in this case (unlike many other cases) at least this > curve is done in the kernel I guess we can then also add a boolean > property to disable the curve (making it linear) in case that > is helpful for HDR scenarios. Hi Hans, what if you would export that curve to userspace and not apply it in the kernel, aside from the min-luminance=0 offset? I'm not sure if that was your intention, I didn't see it clearly said. Of course this can be only about curves that are supposed to be applied by the OS and not applied in firmware or hardware. Call it "software curve"? Let userspace apply that curve if it happens to exist. Then, if we get some other definition replacing that curve on some hardware, the kernel could just expose the other thing as a new thing, and the old curve API would not be interfering. Userspace that does not understand the new thing (and the old curve property is not populated) would still be able to control the brightness, just not in as pleasant way. It would also make using a custom curve a completely userspace thing with no need for the kernel to support overwriting it. Thanks, pq pgpnBFJsxlfaN.pgp Description: OpenPGP digital signature
Re: [RFC v2] drm/kms: control display brightness through drm_connector properties
Hi, On 10/3/22 12:32, Pekka Paalanen wrote: > On Mon, 3 Oct 2022 11:44:56 +0200 > Hans de Goede wrote: > >> One example mentioned here is that laptops with Intel integrated >> graphics may have some "perceived brightness" mapping table >> in their Video BIOS Tables (VBT) it would be interesting to use >> this and to export the curve coming from that to userspace as >> extra information (including allow userspace to write it). >> Since in this case (unlike many other cases) at least this >> curve is done in the kernel I guess we can then also add a boolean >> property to disable the curve (making it linear) in case that >> is helpful for HDR scenarios. > > Hi Hans, > > what if you would export that curve to userspace and not apply it in > the kernel, aside from the min-luminance=0 offset? > > I'm not sure if that was your intention, I didn't see it clearly said. > Of course this can be only about curves that are supposed to be applied > by the OS and not applied in firmware or hardware. Call it "software > curve"? > > Let userspace apply that curve if it happens to exist. Then, if we get > some other definition replacing that curve on some hardware, the kernel > could just expose the other thing as a new thing, and the old curve API > would not be interfering. Userspace that does not understand the new > thing (and the old curve property is not populated) would still be able > to control the brightness, just not in as pleasant way. > > It would also make using a custom curve a completely userspace thing with > no need for the kernel to support overwriting it. Userspace comes in many forms, which is why my preference for "software curve" support would be for it to be applied by the kernel by default (if present in the VBT) but then with a "software curve enable" flag to allow advanced userspace to disable it and then apply a curve of userspace's own choosing itself. This allows a simple implementation for desktop-environments which are unlikely to implement all this themselves, giving everyone the benefit of the nicer behavior of the VBT provided curve while allowing advanced desktop environments (likely mainly KDE + GNOME/mutter) to do something more advanced. Either way, this is all future extensions. First lets get the basic brightness control with just brightness + brightness-max attributes in place. Regards, Hans
Re: Weston window move to second monitor
On 03/10/2022 08:25, Alexandros Frantzis wrote: On Sun, Oct 02, 2022 at 09:13:27AM +0100, Terry Barnaby wrote: Hi, I am developing software for an instrument embedded system using NXP CPU's and the Wayland/Weston GUI system. The hardware platform has a main LCD panel and an optional plug-in HDMI monitor. The GUI is currently running with the Weston kiosk-shell and a single application is shown full screen on the LCD. Weston is configured so that the HDMI monitor appears to the right of the LCD screen and if the desktop-shell is used applications can be dragged across. Now what I would like is for the application to be moved to the HDMI monitor/screen when the monitor is plugged in (resizing as needed). With X11 I would have simply, from the application, moved its top level window coordinates and without a window manager or with a simple window manager the window would move to the area of the second screen. Now I understand that Weston and the standard Wayland protocol's do not even allow a window move request to be made. So I assume I might have to implement a whole new Weston shell, perhaps based on the kiosk-shell, and either invent some form of protocol to allow the application to request the shell to move it or get the shell to see HDMI plug in events and move the application and tell it to resize. I don't have much knowledge of Wayland/Weston internals (lots of X11), so can anyone give me any pointers on how I might achieve this in the simplest/quickest way ? Terry Hi Terry, Assuming you only care about the fullscreen case, an application can request (but not force) a fullscreen placement for a toplevel surface with: xdg_toplevel_set_fullscreen(xdg_toplevel, wl_output) In your application you could listen for advertised wl_output globals and issue a set_fullscreen request for the preferred wl_output (e.g., based on the wl_output/xdg_output name). Since you are only dealing with a specific compositor under your control, you can be fairly confident that you will get consistent behavior here, i.e., the compositor will honor your request. Note that kiosk-shell provides a mechanism in the .ini file to declare the placement of applications on specific outputs. However, the output placement decision is static, made only when the surface is first created/committed to, not for any subsequent output reconfigurations. Making this output placement in kiosk-shell work more dynamically (optionally), with the shell moving the surface to the preferred output, could possibly be a useful enhancement for some use cases. HTH, Alexandros Many thanks for the reply and info. I will have a go with xdg_toplevel_set_fullscreen() and maybe have a look at creating a special shell to do this as well. Actually I have got this working to a degree in a copy of the kiosk-shell adding code to the kiosk_shell_handle_output_created() and kiosk_shell_surface_notify_output_destroy() to move the views. But I can't get the shell to clear its background when I move the application window, indeed it doesn't seem like the kiosk-shell code is actually setting the background at all as looking at the code it should set it to grey but it is black on my system using Weston 9.0.0. I will investigate further. Terry
Re: Weston window move to second monitor
On 03/10/2022 08:25, Alexandros Frantzis wrote: On Sun, Oct 02, 2022 at 09:13:27AM +0100, Terry Barnaby wrote: Hi, I am developing software for an instrument embedded system using NXP CPU's and the Wayland/Weston GUI system. The hardware platform has a main LCD panel and an optional plug-in HDMI monitor. The GUI is currently running with the Weston kiosk-shell and a single application is shown full screen on the LCD. Weston is configured so that the HDMI monitor appears to the right of the LCD screen and if the desktop-shell is used applications can be dragged across. Now what I would like is for the application to be moved to the HDMI monitor/screen when the monitor is plugged in (resizing as needed). With X11 I would have simply, from the application, moved its top level window coordinates and without a window manager or with a simple window manager the window would move to the area of the second screen. Now I understand that Weston and the standard Wayland protocol's do not even allow a window move request to be made. So I assume I might have to implement a whole new Weston shell, perhaps based on the kiosk-shell, and either invent some form of protocol to allow the application to request the shell to move it or get the shell to see HDMI plug in events and move the application and tell it to resize. I don't have much knowledge of Wayland/Weston internals (lots of X11), so can anyone give me any pointers on how I might achieve this in the simplest/quickest way ? Terry Hi Terry, Assuming you only care about the fullscreen case, an application can request (but not force) a fullscreen placement for a toplevel surface with: xdg_toplevel_set_fullscreen(xdg_toplevel, wl_output) In your application you could listen for advertised wl_output globals and issue a set_fullscreen request for the preferred wl_output (e.g., based on the wl_output/xdg_output name). Since you are only dealing with a specific compositor under your control, you can be fairly confident that you will get consistent behavior here, i.e., the compositor will honor your request. Note that kiosk-shell provides a mechanism in the .ini file to declare the placement of applications on specific outputs. However, the output placement decision is static, made only when the surface is first created/committed to, not for any subsequent output reconfigurations. Making this output placement in kiosk-shell work more dynamically (optionally), with the shell moving the surface to the preferred output, could possibly be a useful enhancement for some use cases. HTH, Alexandros Many thanks for the reply and info. I will have a go with xdg_toplevel_set_fullscreen() and maybe have a look at creating a special shell to do this as well. Actually I have got this working to a degree in a copy of the kiosk-shell adding code to the kiosk_shell_handle_output_created() and kiosk_shell_surface_notify_output_destroy() to move the views. But I can't get the shell to clear its background when I move the application window, indeed it doesn't seem like the kiosk-shell code is actually setting the background at all as looking at the code it should set it to grey but it is black on my system using Weston 9.0.0. I will investigate further. Terry
