[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0612071439040.31668@pentafluge.infradead.org>
Date: Thu, 7 Dec 2006 15:20:27 +0000 (GMT)
From: James Simmons <jsimmons@...radead.org>
To: Miguel Ojeda Sandonis <maxextreme@...il.com>
cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Luming.yu@...el.com, zap@...elink.ru, randy.dunlap@...cle.com,
kernel-discuss@...dhelds.org
Subject: Re: Display class
> - I would remove "struct device *dev, void *devdata" of display_device_register()
> Are they neccesary for other display drivers? I have to pass NULL right now.
Yes. Passing in a struct device allows you a link between the device and
the class. If you pass in the device for the parport a link to the parport
device would exist in you displayX directory. The devdata is used by the
probe function to get data about the monitor if it is not NULL.
In the case of most desktop monitors they have EDID blocks. You can
retrieve them (devdata) and it gets parsed thus you have detail data
about the monitor. In your case it can be null.
> - I would add a paramtere ("char *name") to display_device_register() so we
> set the name when registering. Right now I have to set my name after inited,
> and this is a Linux module and not a person borning, right? ;)
The probe function gets this for you. In your case you would have a probe
method that would just fill in the name of the LCD. For me using the ACPI
video driver I get the name for my monitor
LEN 15"XGA 200nit
Which is the manufacturer - monitor id - ascii block.
> - I would add a read/writeable attr called "rate" for set/unset the refresh rate
> of a display.
I suggest creating a group for your driver. See device.h for
group_attributes.
> - I was going to maintain the drivers/auxdisplay/* tree.
> Are you going to maintain the driver? I think so, just for being sure.
Yes. I need it for the ACPI video and fbdev layer. Remember its in the
early stages yet.
> P.S.
>
> When I was working at 2.6.19-rc6-mm2 it worked all fine, but now
> I have copied it to git7 I'm getting some weird segmentation faults
> (oops) when at cfag12864bfb_init, at mutex_lock() in
> display_device_unregister module... I think unrelated (?), but I will
> look for some mistake I made.
Did you solve the problem?
-
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/
Powered by blists - more mailing lists