t yet support that in the kernel either.)
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Wed, 07 Apr 2021, Hans Verkuil wrote:
> On 07/04/2021 12:31, Jani Nikula wrote:
>> On Wed, 07 Apr 2021, Hans Verkuil wrote:
>>> It is the most complete EDID parser I know based on the various standards.
>>
>> Does it support pure DisplayID in addition to Displa
On Thu, 08 Apr 2021, Pekka Paalanen wrote:
> On Thu, 08 Apr 2021 16:49:37 +0300
> Jani Nikula wrote:
>
>> Anyway, this is only tangentially related to the library. I just think
>> we need to take DisplayID better into account also in the *users* of the
>> library, as
On Thu, 08 Apr 2021, Simon Ser wrote:
> On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula
> wrote:
>
>> Perhaps that should be the takeaway; try to minimize parsed data
>> where the consumer needs to know whether it originated from DisplayID or
>> EDID?
>
>
documenting that it
>> >> may turn off the backlight and that userspace _must_ never
>> >> depend on it turning off the backlight.
>> >>
>> >> Also note that setting a direct PWM output to duty-cycle 0%
>> >> does not guarantee that the b
t; Regards,
>
> Hans
>
>
> 1) The need to be able to map the backlight device to a specific display
> has become clear once more with the recent proposal to add DDCDI support:
> https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/
>
> 2)
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> Note this proposal included a method for userspace to be able to tell the
> kernel if the native/acpi_video/vendor backlight device should be used,
> but this has been solved in the kernel for years now:
> https://www.spinics.net/lists/linux-acpi/msg50526.html
> An initial implementation of this proposal is available here:
> https://cgit.freedesktop.org/~mperes/linux/log/?h=backlight
>
--
Jani Nikula, Intel Open Source Graphics Center
On Wed, 27 Apr 2022, Daniel Vetter wrote:
> On Thu, Apr 14, 2022 at 01:24:30PM +0300, Jani Nikula wrote:
>> On Mon, 11 Apr 2022, Alex Deucher wrote:
>> > On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede wrote:
>> >>
>> >> Hi,
>> >>
>> &
of unification we
currently have. DisPLay_brIgh7ne55. :p
I think "display_brightness" is probably fine.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
backlight device to a specific display
> has become clear once more with the recent proposal to add DDCDI support:
> https://lore.kernel.org/lkml/20220403230850.2986-1-yusisameri...@gmail.com/
>
> 2)
> https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
> Note this proposal included a method for userspace to be able to tell the
> kernel if the native/acpi_video/vendor backlight device should be used,
> but this has been solved in the kernel for years now:
> https://www.spinics.net/lists/linux-acpi/msg50526.html
> An initial implementation of this proposal is available here:
> https://cgit.freedesktop.org/~mperes/linux/log/?h=backlight
>
>
--
Jani Nikula, Intel Open Source Graphics Center
t's one that must
> change and we should at least try to create an API which still works
> when we get more and better data.
>
>>
>> Besides, I would expect some backlights to wear over time, grow dimmer
>> for the same input value. Without a physical active feedback loop
g hardware
> overlays on Intel, as expected.
>
> So hardware cursors should be fine again, once the patch also ends in
> stable kernels.
Pushed to our topic/drm-fixes, thanks for the patch and review.
BR,
Jani.
>
> thanks,
> -mario
> ___
11 matches
Mail list logo
