linux-kernel - Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5151D525.3040807@web.de>
Date:	Tue, 26 Mar 2013 18:04:37 +0100
From:	Danny Baumann <dannybaumann@....de>
To:	Chris Wilson <chris@...is-wilson.co.uk>,
	David Airlie <airlied@...ux.ie>,
	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level
 for sysfs control.

Hi,

>> Thus far our assumption always was that the acpi backlight works better
>> than the intel native backlight. So everything only uses the intel
>> backlight if there's no other backlight driver by default.
>
> There are machines, such as the pnv netbook on my desk, on which
> intel_backlight does nothing and the only control is through
> acpi_backlight0.

That's fine - but on my machine, (at least currently) it's the other way 
around. acpi_video[0|1] do nothing, while intel_backlight is the only 
method that works. This sucks (please also see my reply to Daniel), but 
it's a fact.

> Generalising expected behaviour based on one firmware
> implementation is fraught with danger.

I'm not sure what you mean here. I interpret the statement as 'user 
space should treat acpi_videoX and intel_backlight differently'. Is this 
interpretation correct?
If so, how is user space supposed to know how the respective backlight 
device will behave, as this behaviour might change at any point in time 
if there's no understanding in how it _should_ behave? What currently 
happens on my machine is that KDE completely turns off the backlight 
after the dim timeout, because it assumes that the value 0 will keep the 
backlight at a readable level (which would be the case if it used 
acpi_videoX because this behaviour is mandated by the spec there). I 
first thought of sending a patch to KDE, but I couldn't figure out how 
KDE is _supposed_ to correctly handle the situation, especially given 
that the actual sysfs interface used is abstracted away by Xrandr (and 
chosen by the Intel Xorg driver). With my patch, intel_backlight behaves 
in a way that roughly matches the behaviour mandated by the ACPI spec.
Do you have a way in mind that allows fixing this in user space?

Thanks,

Danny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/