[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090804203549.GA25332@kroah.com>
Date: Tue, 4 Aug 2009 13:35:49 -0700
From: Greg KH <greg@...ah.com>
To: Corentin Chary <corentin.chary@...il.com>
Cc: Jakub Schmidtke <sjakub@...il.com>,
acpi4asus-user@...ts.sourceforge.net,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Cleaning asus_oled
On Tue, Aug 04, 2009 at 08:40:10PM +0200, Corentin Chary wrote:
> Hi,
> I'm trying to clean the asus_oled driver, here is my git tree with
> some trivial patchs.
> http://git.iksaif.net/?p=acpi4asus.git;a=shortlog;h=refs/heads/asus_oled
That's great! But note, I need patches in email form, so you are going
to use git format-patch to dig them out for me, right? :)
> Before working deeper, I wanted to discuss about the userspace interface:
>
> > TODO:
> > [...]
> > - audit the userspace interface
> > - sysfs vs. char?
>
> First, should we move asus_oled functionalities in asus-laptop ?
> Then the interface would be in sysfs under
> /sys/devices/platform/asus-laptop/{picture|enable} ?
Is that the way that other drivers of this kind of functionality work
today? If so, yes, that would be good.
> Else we can use /dev/asus_oled, with an ioctl (or a zero-size image)
> to switch the OLED off.
> But I don't think /sys/class/oled is a good place to be, because
> /sys/class is for generic things.
Like /sys/class/video_output? There's got to be some other generic
backlight driver class already, oh, hey, look at /sys/class/backlight!
So, why not just use the backlight interface instead, that way you don't
have to write custom userspace code for this specific platform?
thanks,
greg k-h
--
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/
Powered by blists - more mailing lists