Cleaning asus_oled

Cleaning asus_oled

[Corentin Chary]

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

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} ?

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.

Thanks,

-- 
Corentin Chary
http://xf.iksaif.net - http://uffs.org

Re: Cleaning asus_oled

[Greg KH]

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

Re: Cleaning asus_oled

[Corentin Chary]

On Tue, Aug 4, 2009 at 10:35 PM, Greg KH<greg@kroah.com> 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.

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 ?

Thanks,
-- 
Corentin Chary
http://xf.iksaif.net - http://uffs.org

Re: Cleaning asus_oled

[Greg KH]

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@kroah.com> 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

Re: Cleaning asus_oled

[Corentin Chary]

On Thu, Aug 6, 2009 at 10:01 PM, Greg KH<greg@kroah.com> 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@kroah.com> 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