Twas brillig at 14:12:11 28.04.2010 UTC+02 when [email protected] did gyre and
gimble:
PD> X -- having root privileges
X tries hard to live without root privileges. Well, unless some
brain-damaged API requiring root privileges pops up again.
--
http://fossarchy.blogspot.com/
pgp3V9kKkHmgz
On Wed, Apr 28, 2010 at 01:27:14PM +0200, Kay Sievers wrote:
>
> The backlight is in /sys, everybody with the proper privileges can use
> this text-based interface.
Ok, so, it looks like there is already an interface to the low level
(I guess kernel) stuff through /sys, but the point is that it i
On Wed, Apr 28, 2010 at 7:21 AM, Richard Hughes wrote:
> On 28 April 2010 11:19, Patrice Dumas wrote:
>> What do we do on systems with drivers that don't support randr 1.2? Pretty
>> much all systems with a backlight control use the kernel backlight
>> interface.
>
> Sure, but how many open d
Twas brillig at 13:27:14 28.04.2010 UTC+02 when [email protected] did gyre
and gimble:
KS> It's the other way around. if X is taking control over the screen, it
KS> should take control over the backlight.
KS> Console issues, and custom setups are not really covered here. And I
KS> guess
On Wed, Apr 28, 2010 at 12:19, Patrice Dumas wrote:
> On Wed, Apr 28, 2010 at 11:51:58AM +0200, Kay Sievers wrote:
>>
>> It should be reasonable simple to let X provide internally a generic
>> sysfs backlight driver which can be wired up from individual drivers
>> like radeon.
>
> I am a complete
On 28 April 2010 11:19, Patrice Dumas wrote:
> What do we do on systems with drivers that don't support randr 1.2? Pretty
> much all systems with a backlight control use the kernel backlight interface.
Sure, but how many open drivers don't support RANDR 1.2? And how many
of those have chipsets
On Wed, Apr 28, 2010 at 11:51:58AM +0200, Kay Sievers wrote:
>
> It should be reasonable simple to let X provide internally a generic
> sysfs backlight driver which can be wired up from individual drivers
> like radeon.
I am a complete outsider here, but my first reaction would be to say
that bac
On 28 April 2010 11:03, Kay Sievers wrote:
> Yeah, Intel is already doing it:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/drmmode_display.c?h=7e7db7ac530b5282b0841585959597b54fcc633b#n89
>
> Other drivers just need to do the same, maybe by sharing some pieces
> here, but t
On Wed, Apr 28, 2010 at 11:56, Martin Pitt wrote:
> So, would it be possible to move these ACPI bits into X itself, and
> fall back to them if the driver does not support backlight setting
> itself? Then we would have X, and only X, as the userspace API to
> control backlight.
Yeah, Intel is alre
Richard Hughes [2010-04-28 10:38 +0100]:
> Unless we can convince Alex otherwise, we'll need a trivial
> ubacklight-type-daemon which is system activated for this hardware (or
> a polkit helper root program).
The primary issue with moving those bits to upower back then AFAIR
wasn't that the code i
On Wed, Apr 28, 2010 at 11:38, Richard Hughes wrote:
> Sorry to open an old wound, but it looks like radeon won't be adding
> BACKLIGHT into the driver, ever.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=27859
That surely all belongs into the X server below the randr interface.
The intel driv
Sorry to open an old wound, but it looks like radeon won't be adding
BACKLIGHT into the driver, ever.
https://bugs.freedesktop.org/show_bug.cgi?id=27859
Unless we can convince Alex otherwise, we'll need a trivial
ubacklight-type-daemon which is system activated for this hardware (or
a polkit help
12 matches
Mail list logo
