Re: Why moving driver includes ?

Re: Why moving driver includes ?

[Pete Zaitcev]

>> Why did you move the driver includes to include/video ? What is 
>> the reasoning here ?
>> 
>> For example, drivers/video/radeon.h moved to include/video/radeon.h

> Yes. You never know. The other big reason was so userland could have a 
> standard set of hardware header files to program graphics hardware. Now 
> SDL and directfb etc can use the same header files.

Yeah, but what does it have to do with kernel? You should have
gotten Uli to add them to glibc.

-- Pete

Re: Why moving driver includes ?

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pete Zaitcev wrote:

> Yeah, but what does it have to do with kernel? You should have
> gotten Uli to add them to glibc.

Headers like have no place in glibc either.  There should be one or more
separate packages which distribute kernel headers.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+i4832ijCOnn/RHQRAo+3AJ9VSy96p4dq8DJ+Mtd0oZTCCOswxgCdHl9d
daw5lnlXKUuciCSTKSt3Jxc=
=ugh8
-----END PGP SIGNATURE-----

Re: Why moving driver includes ?

[Pete Zaitcev]

> Date: Wed, 02 Apr 2003 17:32:33 -0800
> From: Ulrich Drepper <drepper@redhat.com>

> > Yeah, but what does it have to do with kernel? You should have
> > gotten Uli to add them to glibc.
> 
> Headers like have no place in glibc either.  There should be one or more
> separate packages which distribute kernel headers.

I can see your point, but imagine how many packages this is
going to create. Shall we plead with Arjan to maintain
glibc-kernelheaders as a community package, to be a clearinghouse
for these things?

-- Pete

Re: Why moving driver includes ?

[Christoph Hellwig]

On Wed, Apr 02, 2003 at 08:40:26PM -0500, Pete Zaitcev wrote:
> I can see your point, but imagine how many packages this is
> going to create. Shall we plead with Arjan to maintain
> glibc-kernelheaders as a community package, to be a clearinghouse
> for these things?

Yes.  It would be nice to have a tarball of it on kernel.org instead
of only the SRPM on rawhide, btw..

Re: Framebuffer fixes.

[James Simmons]

> > > > Shouldn't these be info->var.bits_per_pixel instead of fb_logo.depth?
> > > 
> > > Yes, fb_logo.depth == info->var.bits_per_pixel.
> > 
> > Euh, now I get confused... Do you mean
> > `Yes, it should be replaced by info->var.bits_per_pixel' or
> > `No, logo.depth is always equal to info->var.bits_per_pixel'?
> 
> :)  Sorry about that. I meant:
> 
> 
> `No, fb_logo.depth is always equal to info->var.bits_per_pixel'

No this is no longer true. For example last night I displayed the 16 color 
logo perfectly fine on a 16 bpp display!!!! The mono display still has 
bugs tho. The new logo tries to pick the best image to display. Say for 
example we have two video cards. One running VESA fbdev at 16 bpp and a 
another at vga 4 planar via vga16fb. This way we can have the both the 16 
color and 224 color logo compiled in.  The correct logo will be displayed 
then on the correct display. Now say we only have a mono display but all 
the cards support 8 bpp or better. That logo still gets displayed.



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Why moving driver includes ?

[Benjamin Herrenschmidt]

Hi James !

Why did you move the driver includes to include/video ? What is 
the reasoning here ?

For example, drivers/video/radeon.h moved to include/video/radeon.h

Is this to be able to share register definitions with the DRM drivers ?
(I doubt this will ever happen as the DRM is rather self contained)

I would have preferred those includes to stay next to their respective
drivers (though renaming radeon.h to radeonfb.h might have made some
sense).

Regards,
Ben.



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Why moving driver includes ?

[Benjamin Herrenschmidt]

Hi James !

Why did you move the driver includes to include/video ? What is 
the reasoning here ?

For example, drivers/video/radeon.h moved to include/video/radeon.h

Is this to be able to share register definitions with the DRM drivers ?
(I doubt this will ever happen as the DRM is rather self contained)

I would have preferred those includes to stay next to their respective
drivers (though renaming radeon.h to radeonfb.h might have made some
sense).

Regards,
Ben.

Re: Why moving driver includes ?

[James Simmons]

> Hi James !
> 
> Why did you move the driver includes to include/video ? What is 
> the reasoning here ?
> 
> For example, drivers/video/radeon.h moved to include/video/radeon.h
> 
> Is this to be able to share register definitions with the DRM drivers ?
> (I doubt this will ever happen as the DRM is rather self contained)

Yes. You never know. The other big reason was so userland could have a 
standard set of hardware header files to program graphics hardware. Now 
SDL and directfb etc can use the same header files.