From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: linux-fbdev-devel@lists.sourceforge.net,
Andrew Zabolotny <zap@homelink.ru>
Cc: rpurdie@rpsys.net, russ.dill@gmail.com,
steven.scholz@imc-berlin.de, lenz@cs.wisc.edu
Subject: Re: Re: Backlight support
Date: Thu, 2 Dec 2004 19:08:28 +0800 [thread overview]
Message-ID: <200412021908.28861.adaplas@hotpop.com> (raw)
In-Reply-To: <20041202013437.5d63234e.zap@homelink.ru>
On Thursday 02 December 2004 06:34, Andrew Zabolotny wrote:
> On Tue, 30 Nov 2004 16:28:26 -0000
>
> "Richard Purdie" <rpurdie@rpsys.net> wrote:
> > I think the above patch was nearly there. The issues seemed to be with
> > the method of associating framebuffer devices with their backlights.
> > I've come up with a solution to that problem (see below) so that code
> > can be removed from that patch and that should make it acceptable for
> > mainstream kernel inclusion.
>
> I confirm that the solution you proposed is quite suitable for the job.
> I've already modified the lcd/backlight subsystem, and I have a few
> comments;
>
> a) First of all, the implementation of your idea looks quite well
> (it's simpler and cleaner than the old method), although initially I
> didn't like it (mea culpa). I have removed a lot of now unneeded code
> from b/l support, and also it removes a lot of lcd/backlight
> maintainance code from the framebuffer drivers(pxafb, sa11xxfb,
> mq11xxfb). Last but not least, it removed the class_find_device()
> function that was the sticking point in the discussion with gkh.
>
> b) No modification is needed to the existing lcd/backlight drivers
> (there are about ten of them in hh.org cvs). I've added just one more
> function pointer in the lcd_properties and backlight_properties to a
> function that gets a fb_info and examinates if it is the
> framebuffer to which the lcd/backlight is attached to. If the function
> is NULL, the framebuffer is considered to match (since in PDAs there's
> only one framebuffer, this perfectly fits already existing drivers).
>
> c) There's a problem though; if someone will REALLY want to inspect
> the fb_info, it would be very helpful to be able to deduce somehow the
> 'struct device' associated with the framebuffer, since the fb_info
We already have a struct device field in fb_info. It was initially requested
for swsusp2, but I find that it has other uses as well (in userland).
Tony
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
prev parent reply other threads:[~2004-12-02 11:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <40ED4FAC.70406@ticino.com>
[not found] ` <1089274696.4740.3.camel@localhost>
[not found] ` <41AB2E71.8080809@imc-berlin.de>
[not found] ` <f9d2a5e104112916252c253a2b@mail.gmail.com>
2004-11-30 16:28 ` Backlight support Richard Purdie
2004-11-30 16:44 ` Nicolas Pitre
2004-11-30 22:40 ` Russ Dill
2004-12-01 22:34 ` Andrew Zabolotny
2004-12-02 11:08 ` Antonino A. Daplas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200412021908.28861.adaplas@hotpop.com \
--to=adaplas@hotpop.com \
--cc=lenz@cs.wisc.edu \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=rpurdie@rpsys.net \
--cc=russ.dill@gmail.com \
--cc=steven.scholz@imc-berlin.de \
--cc=zap@homelink.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.