Re: Display class

[James Simmons <jsimmons@infradead.org>]

>   - 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/