https://bugs.freedesktop.org/show_bug.cgi?id=27859
--- Comment #11 from Alex Deucher <[email protected]> 2010-04-29 08:52:30 PDT --- (In reply to comment #10) > > Well, this is not about a second mechanic controlling the same thing, it's > just > about a common higher-level interface on top of whatever is in charge of > actual > controlling the hardware. That it's using the low-level sysfs stuff on Linux > is > just an implementation detail that the higher-level randr interface should not > export to desktop-like stuff at all. > > The X/non-X logic is actually the other way around, it's: if X controls the > screen, it should also control the backlight belonging to the screen. And > non-X > custom use cases are obviously not touched at all by an interface provided by > X. :) > It is irrelevant whether the backlight change comes through some xrandr wrapper that uses the backlight interface or the backlight interface directly. It just adds indirection. > And the actual driver in X could be shared between all drivers if that is your > concern. It could even be extended to support more than sysfs if needed, and > all that logic would live well behind randr and not need to leak into any > other > crufty userspace logic. If someone wants to add some common X interface for exposing backlight control, fine by me, but it seems like a lot of pointless work. All this does is add a layer of indirection just because. We have: 1. gpm uses backlight interface directly: gpm -> kernel backlight interface 2. gpm uses xrandr: gpm -> xrandr -> xserver -> ddx -> drm -> kernel backlight interface Not only is there a lot more indirection, it also involves having to code all that stuff in between. Plus, no one has yet addressed how we deal with non-xrandr-1.2 capable drivers. What do you do on a laptop with a savage or some old nv chip? Or some pda or tablet that uses some fbdev hack? How does gpm deal with that? Who's going to go and add xrandr-1.2 support to all these old drivers? I guess in those cases we can add a special hack to gpm. > > That all seems pretty simple and consistent to me. :) What does this gain us? Seems to me, it's just a lot of work in lots of places just so we can use another interface that does the same thing that an existing common interface already does. Maybe we should add an xrandr interface to adjust the sound card volume. If X is running, why not use xrandr to adjust the volume? I know there's a standard way to access the sound card, but X is running and it should have it's own way. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
