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]

Date:	Wed, 5 Aug 2009 09:54:47 +0200
From:	Corentin Chary <corentin.chary@...il.com>
To:	Greg KH <greg@...ah.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 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.

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
--
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/