Messages in this thread | | | Date | Thu, 7 Dec 2006 17:21:13 +0100 | From | "Miguel Ojeda" <> | Subject | Re: Display class |
| |
On 12/7/06, James Simmons <jsimmons@infradead.org> wrote: > > > - 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? >
I didn't look further, but I will be able to try again in some hours. Anyway, the problem is probably at cfag12864bfb.c (as it was almost the only file I modified from -mm2); but I can't tell where the problem is as I tried just a few times.
Please review cfag12864bfb_init/_exit to check if your code/class is intended to be used that way, I will focus on the segfaults.
Greets!
-- Miguel Ojeda http://maxextreme.googlepages.com/index.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |