[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54FECC2F.8080804@ti.com>
Date: Tue, 10 Mar 2015 12:49:19 +0200
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Maxime Ripard <maxime.ripard@...e-electrons.com>,
Thomas Niederprüm <niederp@...sik.uni-kl.de>
CC: <linux-fbdev@...r.kernel.org>, <plagnioj@...osoft.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/8] fbdev: ssd1307fb: Add sysfs handles to expose contrast
and dim setting to userspace.
On 09/02/15 10:52, Maxime Ripard wrote:
> On Sat, Feb 07, 2015 at 05:42:44PM +0100, Thomas Niederprüm wrote:
>>>> +static struct device_attribute device_attrs[] = {
>>>> + __ATTR(contrast, S_IRUGO|S_IWUSR, show_contrast,
>>>> store_contrast),
>>>> + __ATTR(dim, S_IRUGO|S_IWUSR, show_dim, store_dim),
>>>> +
>>>> +};
>>>> +
>>>
>>> I would have thought this was something accessible through the
>>> framebuffer ioctl.
>>>
>>> Apparently it's not, at least for the contrast, so maybe it should be
>>> added there, instead of doing it for a single driver?
>>
>> I think the contrast setting for an OLED display is much like the
>> backlight setting for LCD panel. Since there is also no ioctl to set
>> the backlight of an LCD I wonder if the contrast of an OLED should have
>> one.
>
> It's too much of framebuffer interface debate for me here. Tomi?
We have backlight and contrast already in backlight-class and lcd-class
(drivers/video/backlight/backlight.c and drivers/video/backlight/lcd.c).
Are those something that could be used here instead of custom sysfs files?
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists