Re: Cleaning asus_oled
From: Corentin Chary
Date: Tue Sep 08 2009 - 17:39:43 EST
On Thu, Aug 6, 2009 at 10:01 PM, Greg KH<greg@xxxxxxxxx> wrote:
>
On Wed, Aug 05, 2009 at 09:54:47AM +0200, Corentin Chary wrote:
>
> On Tue, Aug 4, 2009 at 10:35 PM, Greg KH<greg@xxxxxxxxx> wrote:
>
> > 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? :)
>
>
>
> Yes, of course.
>
>
>
> >> 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.
>
>
>
> Hum, actually I think it is not a good idea. It is just an USB device, and
>
> Asus may wan't to use it on motherboard on day. We should keep it
>
> a simple usb driver.
>
>
>
> >> 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?
>
>
>
> backlight interface is only to change screen brightness, so we can't
>
> use that for an oled screen. There is an lcd class too, but it is used
>
> for contrast.
>
>
>
> After some grepping in the kernel, it seems that there is no generic
>
> lcd interface.
>
> For example :
>
> - drivers/parisc/led.c use a /proc/pdc/lcd file
>
> - drivers/ans-lcd.c use a /dev/anslcd file
>
>
>
> If you look at http://ssl.bulix.org/projects/lcd4linux/browser/trunk
>
>
>
> You'll see a lot of drv_***.c files, and each of them are for a
>
> different kernel interface
>
> (although some of them might don't use any interface).
>
>
>
> It seems that http://lcd-linux.sourceforge.net/ try to implement a
>
> generic interface,
>
> but only for alphanumeric displays, and it is not in mainline.
>
>
But we could add it, right? Care to ask those developers if we can do
>
that?
>
>
> This also could be a classic frambuffer device, but I don't think it's
>
> the best way to go for this type of device.
>
>
>
> Time to write a generic oled/lcd pannel class ?
>
>
Probably :)
>
>
have fun,
>
>
greg k-h
>
Hi,
I've seen your thread about the staging tree status.
I'm currently trying to get the hardware to work on asus_oled.
If I can get it, I'll maintain this driver as a part of the acpi4asus project.
Else, we will need to find another maintainer =).
Thanks,
--
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/