linux-kernel - Re: Cleaning asus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090806200127.GD29827@kroah.com>
Date:	Thu, 6 Aug 2009 13:01:27 -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 Wed, Aug 05, 2009 at 09:54:47AM +0200, Corentin Chary wrote:
> On Tue, Aug 4, 2009 at 10:35 PM, Greg KH<greg@...ah.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
--
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/