On Sat, Jan 13, 2007 at 10:40:55PM +, James Simmons wrote:
>
> > Hi,
> >
> > On Tuesday 05 December 2006 13:03, James Simmons wrote:
> > > +int probe_edid(struct display_device *dev, void *data)
> > > +{
> > > +???struct fb_monspecs spec;
> > > +???ssize_t size = 45;
>
> That code wa
On Sat, Jan 13, 2007 at 10:40:55PM +, James Simmons wrote:
>
> > Hi,
> >
> > On Tuesday 05 December 2006 13:03, James Simmons wrote:
> > > +int probe_edid(struct display_device *dev, void *data)
> > > +{
> > > +???struct fb_monspecs spec;
> > > +???ssize_t size = 45;
>
> That code wa
> Hi,
>
> On Tuesday 05 December 2006 13:03, James Simmons wrote:
> > +int probe_edid(struct display_device *dev, void *data)
> > +{
> > + struct fb_monspecs spec;
> > + ssize_t size = 45;
That code was only for testing. I do have new core code. Andrew could
you merge this patch as
Hi,
On Tuesday 05 December 2006 13:03, James Simmons wrote:
> +int probe_edid(struct display_device *dev, void *data)
> +{
> + struct fb_monspecs spec;
> + ssize_t size = 45;
const ssize_t size = 45?
> +
> + dev->name = kzalloc(size, GFP_KERNEL);
Why do you need kzalloc here?
On 12/7/06, James Simmons <[EMAIL PROTECTED]> wrote:
> 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
On 12/7/06, James Simmons <[EMAIL PROTECTED]> 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 an
> - 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 par
On Wed, 6 Dec 2006 15:10:44 + (GMT) James Simmons wrote:
>
> > > of Mr. Yu for acpi. Also this class could in time replace the lcd class
> > > located in the backlight directory since a lcd is a type of display.
> > > The final hope is that the purpose auxdisplay could fall under this
> > >
> > > > That patch was rought draft for feedback. I applied your comments. This
> > > > patch actually works. It includes my backlight fix as well.
> > >
> > > Glad to hear it. I had to make the following changes
> > > in order for it to build.
> > > However, I still have build errors for aty.
On 12/6/06, Miguel Ojeda Sandonis <[EMAIL PROTECTED]> wrote:
Ok, here is the patch (against git7+displayclass) which moves auxdisplay/*
to video/display/* and start using the display class.
It is just a draft, but there isn't much code changed from -mm2.
- I would remove "struct device *dev,
On Wed, 6 Dec 2006 18:24:08 + (GMT) James Simmons wrote:
>
> > > That patch was rought draft for feedback. I applied your comments. This
> > > patch actually works. It includes my backlight fix as well.
> >
> > Glad to hear it. I had to make the following changes
> > in order for it to bui
Ok, here is the patch (against git7+displayclass) which moves auxdisplay/*
to video/display/* and start using the display class.
It is just a draft, but there isn't much code changed from -mm2.
- I would remove "struct device *dev, void *devdata" of
display_device_register()
Are they necce
> > That patch was rought draft for feedback. I applied your comments. This
> > patch actually works. It includes my backlight fix as well.
>
> Glad to hear it. I had to make the following changes
> in order for it to build.
> However, I still have build errors for aty.
Ug. I see another probl
On Wed, 6 Dec 2006 15:10:44 + (GMT) James Simmons wrote:
>
> > > of Mr. Yu for acpi. Also this class could in time replace the lcd class
> > > located in the backlight directory since a lcd is a type of display.
> > > The final hope is that the purpose auxdisplay could fall under this
> > >
> > of Mr. Yu for acpi. Also this class could in time replace the lcd class
> > located in the backlight directory since a lcd is a type of display.
> > The final hope is that the purpose auxdisplay could fall under this
> > catergory.
> >
> > P.S
> >I know the edid parsing would have to be
On 12/5/06, James Simmons <[EMAIL PROTECTED]> wrote:
This is the pass at a display class to meet the needs of the output class
of Mr. Yu for acpi. Also this class could in time replace the lcd class
located in the backlight directory since a lcd is a type of display.
The final hope is that the p
On Tue, 5 Dec 2006 18:03:39 + (GMT) James Simmons wrote:
> This is the pass at a display class to meet the needs of the output class
> of Mr. Yu for acpi. Also this class could in time replace the lcd class
> located in the backlight directory since a lcd is a type of display.
> The final ho
17 matches
Mail list logo
