linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Re: fbcon scrolling madness + fbset corruption

[Antonino D. <ad...@po...>]

On Mon, 2003-02-03 at 03:57, Russell King wrote:
> On Mon, Jan 20, 2003 at 09:29:38AM +0800, Antonino Daplas wrote:
> > fb_pan_display() does not test for YWRAP.  Can you try this?
> 
> This doesn't appear to solve the ywrap problem - I still get
> places where the screen doesn't scroll.  I decided to write a
> small program to dump out the contents of fb_var_screeninfo, and
> where stuff goes horribly wrong:
> 
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+2352
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+2392
> 
> Up to the point where it goes wrong:
> 
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+528
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+568
> bash-2.04# ./tst
> Visible: 1280x1024	<--- this is the last line on the screen
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+608
> bash-2.04#
> 
> So it looks like something isn't limiting the yoffset in the generic
> console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> is just nonsense.

It might be a problem with display.vrows not being updated during
fbcon_resize().  I think I sent James some patches before that added
that.

Can you try adding this at the end of fbcon_resize() in
drivers/video/fbcon.c?

p->vrows = info->var.yres_virtual/vc->vc_font.height;

Tony

PS:  I never encountered your problem, but I don't have hardware that's
capable of ywrap.

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Antonino D. <ad...@po...>]

On Thu, 2003-02-06 at 03:17, Torrey Hoffman wrote:
> > > On Sun, 12 Jan 2003, Geert Uytterhoeven wrote:
> > > > The current logo code is messy, complex, and inflexible. So I decided to
> > > > rewrite it. My goals were:
> [ good list ]
> 
> This is wonderful.  I (and some co-conspirators) started a similar
> project, and put up patches at www.arnor.net/linuxlogo . But yours is up
> to date, and ours is not (I was waiting until the framebuffer rewrite
> was done, and then I didn't have time to catch up).  
> 
> It would be great if your patch was merged.  If I may offer some
> suggestions... well, feature requests :-)
> 
> It would also be nice to have an option to turn off the blinking cursor

You can control some of the attributes of the cursor in 2.5.  The
examples illustrated in linux/Documentation/VGA-Softcursor.txt should
work.  

Tony

Re: [Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[Antonino D. <ad...@po...>]

On Wed, 2003-02-05 at 23:03, Geert Uytterhoeven wrote:
> On 8 Jan 2003, Antonino Daplas wrote:
> > 1.  Changed meaning of image.depth.  If image.depth == 0, it flags for
> > color expansion, otherwise, it flags for image drawing (without color
> > expansion).  This change is to accomodate monochrome cards so they can
> > differentiate character drawing from logo drawing.
> 
> What's the status of this issue? Monochrome is still broken due to this.
> 
It's still the same :-(

Tony

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Antonino D. <ad...@po...>]

On Wed, 2003-02-05 at 20:37, Geert Uytterhoeven wrote:
> On Tue, 28 Jan 2003, Geert Uytterhoeven wrote:
> > On Sun, 12 Jan 2003, Geert Uytterhoeven wrote:
> > > The current logo code is messy, complex, and inflexible. So I decided to
> > > rewrite it. My goals were:
> > >   - Logos must be accessible easily by an image editor (currently: hex C source
> > >     data must be converted to another format first)
> > >   - Logos must be stored in ASCII-form in the source tree
> > >   - Support arbitrary logo sizes (currently: fixed 80x80)
> > >   - Allow the logo to be selected statically (at compile time) and/or
> > >     dynamically (at run-time, based on machine type) (currently: at compile
> > >     time only).
> > >   - Allow simple adition of new logos
> > >   - Support grayscale logos (not used yet)
> > > 
> > > The patch achieves all of these. Logos are stored in ASCII PNM format in
> > > drivers/video/logo/, and automatically converted to hex C source arrays using
> > > scripts/pnmtologo. I chose ASCII PNM because (a) it's ASCII, (b) it's very
> > > simple to parse without an external library (XPM is more difficult to parse),
> > > and (c) it can be handled by many image manipulation programs.
> > > 
> > > Code that wants to display a logo just calls fb_find_logo(), specifying the
> > > wanted logo type, and receives a pointer to a suitable logo (or NULL).
> > > 
> > > I also modified fb_show_logo() to return the number of scanlines that are used
> > > by the logo, so fbcon knows how many lines to reserve.
> > 
> > I put a new version at
> > 
> >     http://home.tvd.be/cr26864/Linux/fbdev/linux-logo-2.5.59.diff.bz2
> > 
> > Changes:
> >   - Merge with 2.5.59
> >   - New logo (CLUT224 only) for PA-RISC
> >   - Let hgafb and newport_con include logo sources directly, since they need
> >     access to the logos in non-init code
> > 
> > All comments are welcomed! Thanks!
> 
> Come on, is there really no one to comment on this??
> 

Actually, I tried the patch before, but it was erased so fast that I
never got to see the logo :-)

Anyway, I think it's because logo_lines require logo_height in
fbcon_set_display().  logo_height is returned by fb_show_logo(), however
fb_show_logo() is called after computing logo_lines.

So, how about breaking up fb_show_logo() into fb_prepare_logo() and
fb_show_logo()?  We can call fb_prepare_logo() to get the logo height
for the logo_lines, then do an fb_show_logo() for the actual drawing.

Also I noticed that the type of logo depends solely on the framebuffer
depth.  This is not necessarily correct.  DirectColor at <24bpp 
requires a 4-bit logo.

Overall, I like it, though it does add some kilobytes to the kernel
image size.

Tony

BTW: Do you know of any logo images that are compatible with your patch?
I'm beginning to get tired of seeing Tux always:-)

diff -Naur linux-2.5.59-gu/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.59-gu/drivers/video/console/fbcon.c	2003-02-05 06:37:49.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2003-02-05 06:38:52.000000000 +0000
@@ -958,6 +958,7 @@
 		int cnt;
 		int step;
 
+		logo_height = fb_prepare_logo(info);
 		logo_lines = (logo_height + vc->vc_font.height - 1) /
 			     vc->vc_font.height;
 		q = (unsigned short *) (vc->vc_origin +
@@ -1944,8 +1945,7 @@
 		accel_clear_margins(vc, p, 0);
 	if (logo_shown == -2) {
 		logo_shown = fg_console;
-		/* This is protected above by initmem_freed */
-		logo_height = fb_show_logo(info);
+		fb_show_logo(info);	/* This is protected above by initmem_freed */
 		update_region(fg_console,
 			      vc->vc_origin + vc->vc_size_row * vc->vc_top,
 			      vc->vc_size_row * (vc->vc_bottom -
diff -Naur linux-2.5.59-gu/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.59-gu/drivers/video/fbmem.c	2003-02-05 06:33:48.000000000 +0000
+++ linux/drivers/video/fbmem.c	2003-02-05 06:36:03.000000000 +0000
@@ -511,101 +511,119 @@
  * We isolate each bit and expand each into a byte. The "needs_logo" flag will
  * be set to 1.
  */
-int fb_show_logo(struct fb_info *info)
-{
-	unsigned char *fb = info->screen_base, *logo_new = NULL;
-	u32 *palette = NULL, *saved_pseudo_palette = NULL;
-	int needs_directpalette = 0;
-	int needs_truepalette = 0;
-	int needs_cmapreset = 0;
-	struct fb_image image;
-	const struct linux_logo *logo = 0;
+static struct logo_data {
+	int depth;
+	int needs_logo;
+	int needs_directpalette;
+	int needs_truepalette;
+	int needs_cmapreset;
 	int type;
-	int needs_logo = 0;
-	int done = 0, x;
-
-	/* Return if the frame buffer is not mapped */
-	if (!fb || !info->fbops->fb_imageblit)
-		return 0;
+	const struct linux_logo *logo;
+} fb_logo;
 
-	image.depth = info->var.bits_per_pixel;
-
-	/* reasonable default */
-	if (image.depth >= 8)
-		type = LINUX_LOGO_CLUT224;
-	else if (image.depth >= 4)
-		type = LINUX_LOGO_VGA16;
-	else
-		type = LINUX_LOGO_MONO;
-
-	/* Return if no suitable logo was found */
-	logo = fb_find_logo(type);
-	if (!logo || logo->height > info->var.yres)
-		return 0;
+int fb_prepare_logo(struct fb_info *info)
+{
+	memset(&fb_logo, 0, sizeof(struct logo_data));
 
-	image.data = logo->data;
+	fb_logo.depth = info->var.bits_per_pixel;
 
 	switch (info->fix.visual) {
 	case FB_VISUAL_TRUECOLOR:
-		needs_truepalette = 1;
-		if (image.depth >= 4 && image.depth <= 8)
-			needs_logo = 4;
-		else if (image.depth < 4)
-			needs_logo = 1;
+		if (fb_logo.depth > 8) {
+			fb_logo.needs_truepalette = 1;
+			fb_logo.needs_logo = 8;
+		} else if (fb_logo.depth >= 4 && fb_logo.depth <= 8)
+			fb_logo.needs_logo = 4;
+		else 
+			fb_logo.needs_logo = 1;
 		break;
 	case FB_VISUAL_DIRECTCOLOR:
-		if (image.depth >= 24) {
-			needs_directpalette = 1;
-			needs_cmapreset = 1;
+		if (fb_logo.depth >= 24) {
+			fb_logo.needs_directpalette = 1;
+			fb_logo.needs_cmapreset = 1;
+			fb_logo.needs_logo = 8;
 		}
 		/* 16 colors */
-		else if (image.depth >= 16)
-			needs_logo = 4;
+		else if (fb_logo.depth >= 16)
+			fb_logo.needs_logo = 4;
 		/* 2 colors */
 		else
-			needs_logo = 1;
+			fb_logo.needs_logo = 1;
 		break;
 	case FB_VISUAL_MONO01:
 		/* reversed 0 = fg, 1 = bg */
-		needs_logo = ~1;
+		fb_logo.needs_logo = ~1;
 		break;
 	case FB_VISUAL_MONO10:
-		needs_logo = 1;
+		fb_logo.needs_logo = 1;
 		break;
 	case FB_VISUAL_PSEUDOCOLOR:
 	default:
-		if (image.depth >= 8)
-			needs_cmapreset = 1;
+		if (fb_logo.depth >= 8) {
+			fb_logo.needs_cmapreset = 1;
+			fb_logo.needs_logo = 8;
+		}
 		/* fall through */
 	case FB_VISUAL_STATIC_PSEUDOCOLOR:
 		/* 16 colors */
-		if (image.depth >= 4 && image.depth < 8)
-			needs_logo = 4;
+		if (fb_logo.depth >= 4 && fb_logo.depth < 8)
+			fb_logo.needs_logo = 4;
 		/* 2 colors */
-		else if (image.depth < 4)
-			needs_logo = 1;
+		else if (fb_logo.depth < 4)
+			fb_logo.needs_logo = 1;
 		break;
 	}
 
-	if (needs_cmapreset)
-		fb_set_logocmap(info, logo);
+	if (fb_logo.needs_logo >= 8)
+		fb_logo.type = LINUX_LOGO_CLUT224;
+	else if (fb_logo.needs_logo >= 4)
+		fb_logo.type = LINUX_LOGO_VGA16;
+	else
+		fb_logo.type = LINUX_LOGO_MONO;
 
-	if (needs_truepalette || needs_directpalette) {
+	/* Return if no suitable logo was found */
+	fb_logo.logo = fb_find_logo(fb_logo.type);
+	if (!fb_logo.logo || fb_logo.logo->height > info->var.yres)
+		return 0;
+	return fb_logo.logo->height;
+}
+
+int fb_show_logo(struct fb_info *info)
+{
+	unsigned char *fb = info->screen_base, *logo_new = NULL;
+	u32 *palette = NULL, *saved_pseudo_palette = NULL;
+	struct fb_image image;
+	int done = 0, x;
+
+	/* Return if the frame buffer is not mapped */
+	if (!fb || !info->fbops->fb_imageblit ||
+	    !fb_logo.depth)
+		return 0;
+
+	image.depth = fb_logo.depth;
+	image.data = fb_logo.logo->data;
+
+	if (fb_logo.needs_cmapreset)
+		fb_set_logocmap(info, fb_logo.logo);
+
+	if (fb_logo.needs_truepalette || 
+	    fb_logo.needs_directpalette) {
 		palette = kmalloc(256 * 4, GFP_KERNEL);
 		if (palette == NULL)
 			return 0;
 
-		if (needs_truepalette)
-			fb_set_logo_truepalette(info, logo, palette);
+		if (fb_logo.needs_truepalette)
+			fb_set_logo_truepalette(info, fb_logo.logo, palette);
 		else
-			fb_set_logo_directpalette(info, logo, palette);
+			fb_set_logo_directpalette(info, fb_logo.logo, palette);
 
 		saved_pseudo_palette = info->pseudo_palette;
 		info->pseudo_palette = palette;
 	}
 
-	if (needs_logo) {
-		logo_new = kmalloc(logo->width * logo->height, GFP_KERNEL);
+	if (fb_logo.needs_logo != 8) {
+		logo_new = kmalloc(fb_logo.logo->width * fb_logo.logo->height, 
+				   GFP_KERNEL);
 		if (logo_new == NULL) {
 			if (palette)
 				kfree(palette);
@@ -615,27 +633,27 @@
 		}
 
 		image.data = logo_new;
-		fb_set_logo(info, logo, logo_new, needs_logo);
+		fb_set_logo(info, fb_logo.logo, logo_new, fb_logo.needs_logo);
 	}
 
-	image.width = logo->width;
-	image.height = logo->height;
+	image.width = fb_logo.logo->width;
+	image.height = fb_logo.logo->height;
 	image.dy = 0;
 
-	for (x = 0; x < num_online_cpus() * (logo->width + 8) &&
-	     x <= info->var.xres-logo->width; x += (logo->width + 8)) {
+	for (x = 0; x < num_online_cpus() * (fb_logo.logo->width + 8) &&
+	     x <= info->var.xres-fb_logo.logo->width; x += (fb_logo.logo->width + 8)) {
 		image.dx = x;
 		info->fbops->fb_imageblit(info, &image);
 		done = 1;
 	}
-
+	
 	if (palette != NULL)
 		kfree(palette);
 	if (saved_pseudo_palette != NULL)
 		info->pseudo_palette = saved_pseudo_palette;
 	if (logo_new != NULL)
 		kfree(logo_new);
-	return logo->height;
+	return fb_logo.logo->height;
 }
 
 static int fbmem_read_proc(char *buf, char **start, off_t offset,
@@ -1213,6 +1231,7 @@
 EXPORT_SYMBOL(num_registered_fb);
 EXPORT_SYMBOL(registered_fb);
 EXPORT_SYMBOL(fb_show_logo);
+EXPORT_SYMBOL(fb_prepare_logo);
 EXPORT_SYMBOL(fb_set_var);
 EXPORT_SYMBOL(fb_blank);
 EXPORT_SYMBOL(fb_pan_display);
diff -Naur linux-2.5.59-gu/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.59-gu/include/linux/fb.h	2003-02-05 06:39:34.000000000 +0000
+++ linux/include/linux/fb.h	2003-02-05 06:40:30.000000000 +0000
@@ -464,6 +464,7 @@
 /* drivers/video/fbmem.c */
 extern int register_framebuffer(struct fb_info *fb_info);
 extern int unregister_framebuffer(struct fb_info *fb_info);
+extern int fb_prepare_logo(struct fb_info *fb_info);
 extern int fb_show_logo(struct fb_info *fb_info);
 extern struct fb_info *registered_fb[FB_MAX];
 extern int num_registered_fb;

Re: [Linux-fbdev-devel] Re: [wx-dev] Linux GUI considerations

[Jon S. <jon...@ya...>]

--- Otto Wyss <ott...@bl...> wrote:
> What alternatives are there?

Use OpenGL as your base API.  
http://fbdri.sourceforge.net/

Framebuffer would be used to initialize the hardware
and handle VT switches. DRM would coordinate with FB
on the VT swtiches so that X could also be run if you
want it.

OpenGL contains a fine 2D API in addition to the 3D
one everyone knows about. 


=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Linux-fbdev-devel] Re: [wx-dev] Linux GUI considerations

[Sven L. <lu...@dp...>]

On Wed, Feb 05, 2003 at 08:44:00PM +0100, Otto Wyss wrote:
> > From: Julian Smart
> > I would certainly be keen to encourage better uptake of Linux through
> > use of wxWindows, but I have to take issue with the argument that
> > a framebuffer-based approach is going to help this. XFree86 has had years
> > of development and tweaking. Are you really saying that we could
> > write a better X11 replacement? Even if we did and managed to write
> > a 3rd super-duper desktop environment with all the required little apps,
> > we'd face a huge struggle in persuading people to use our particular
> > environment instead of X11.
> > 
> XFree86 has done a tremendous amount of effort. Still large part of this
> is simply spent in the wrong places. Instead of keeping writing directly
> to the hardware they should concentrate in building kernel drivers,
> maybe separate maybe together with the framebuffer people. Currently it

Well, remember that X don't run on just Linux, so i guess they are
afraid of duplicating the work, having to rewrite the driver for each OS
they run on. And as a X driver writer, i understand that concern.

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: [wx-dev] Linux GUI considerations

[Otto W. <ott...@bl...>]

> From: Julian Smart
> I would certainly be keen to encourage better uptake of Linux through
> use of wxWindows, but I have to take issue with the argument that
> a framebuffer-based approach is going to help this. XFree86 has had years
> of development and tweaking. Are you really saying that we could
> write a better X11 replacement? Even if we did and managed to write
> a 3rd super-duper desktop environment with all the required little apps,
> we'd face a huge struggle in persuading people to use our particular
> environment instead of X11.
> 
XFree86 has done a tremendous amount of effort. Still large part of this
is simply spent in the wrong places. Instead of keeping writing directly
to the hardware they should concentrate in building kernel drivers,
maybe separate maybe together with the framebuffer people. Currently it
looks close to that they fear anybody may come up with a better X
solution if the hardware part is made generally available. A second
part, the network part, is in a desktop environment or a PDA simply not
necessary but it's not possible to get rid of it. And can you explain
why VNC created their own protocol?

> >I fully agree with James Simmons when he complains about "Linux will
> >NEVER move into the desktop market!" (See
> 
> Chicken/egg...
> 
Yes but if nobody starts to build eggs out of "nothing" you'll never get chickens.

> I may be missing your line of reasoning here, but I think the main
> reason for lack of Linux uptake in the home is the lack of software,
> in particular games (pity Loki didn't succeed). So rather than
> invest in an entirely new GUI solution, perhaps the effort would
> be better spent on porting or writing games and other software...
> as well as trying to persuade more companies to release on
> Linux (by telling them how easy wxWindows is to develop with!)
> 
There will be never any successful Linux gaming business as long as
graphic cards manufactures don't provide their own written Linux
drivers. Again a chicken/egg situation.

> From: Robert Roebling 
> > why isn't there already a framebuffer port
> > in wxWindows?
>
This was more a rhetorical question for the framebuffer people.

> From: Vadim Zeitlin
> RR> > why isn't there already a framebuffer port
> RR> > in wxWindows?
> 
>  FB port could be useful for the devices such as PDA and, especially
> considering that it shouldn't be that difficult to create a wxFB port, I
> hope that this is going to happen if any interesting FB-based systems
> appear. For now I don't know of any however.
> 
IMO an FB port isn't even for PDA's a real alternative, since in a few
years PDA's will have the same power as desktop systems and requests
similar GUIs.

> RR> The Linux desktop will be based on X11 or it
> RR> will not happen at all.
> 
>  And I'd really like to sign under this. I really don't understand why so
> many people hate X so much. IMHO it's a very decent system. As for the
> Linux desktop, it is alive and well alive. Whatever you may think of KDE (I
> don't think much as I never used it myself anyhow) it's an amazingly
> successful project.
> 
Just look at the decision of the "Deutsche Bundestag" about using Linux
on the desktop (with KDE and OpenOffice). 

> From: Julian Smart
> Interesting. Here's another relevant story from today -- a Desktop Linux
> Consortium:
> 
> http://www.internetnews.com/ent-news/article.php/1579921
> 
Really interesting, especially the sencence about "end-users" shows that
I'm on the right track. 


What alternatives are there?

- sticking with X11: While this is currently the only working solution,
Linux won't get a widespread acceptance. It will silently evolve in its
niche but won't break out of it.

- trying a framebuffer port: This won't be successful as long as the
single application approach is overcome (also for PDA).

- trying a DirectFB port: This might be an alternative but my knowledge
is too small to say more. Someone with more insight should have a look.

- using QT: This might help Linux but it's no alternative for wxWindows.

- changing X11: I have absolute no wish to get into a flame ware with
the XFree86 people.

- reactivating Dinx: From the echo in the kernel mailing list this isn't
an option. Maybe it could be integrated into the framebuffer but this is
up to them.

- building a new API: As Julian said this is probably out of question.
Much too much work and persuasion has to be done. 

- re implementing a current API: IMO the only possible way is to take
the Xlib API, leave away any unnecessary functionality and re implement
it based on the framebuffer.

- others: Suggestions?

If you question if this is altogether possible, look at MacOS X. Why can
Apple build a GUI on top of FreeBSD without requiring a single line of
configuration from the user? Why can't this be done with Linux? Besides
why has MacOS a GUI right from the start but Linux hasn't? Besides MacOS
is famous for building a GUI where an ordinary user feels comfortable
with. IMO this should be equally possible for Linux and wxWindows and
not even that difficult. I'm not saying it isn't much work but it's
doable. 

O. Wyss

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Torrey H. <tho...@ar...>]

> > On Sun, 12 Jan 2003, Geert Uytterhoeven wrote:
> > > The current logo code is messy, complex, and inflexible. So I decided to
> > > rewrite it. My goals were:
[ good list ]

This is wonderful.  I (and some co-conspirators) started a similar
project, and put up patches at www.arnor.net/linuxlogo . But yours is up
to date, and ours is not (I was waiting until the framebuffer rewrite
was done, and then I didn't have time to catch up).  

It would be great if your patch was merged.  If I may offer some
suggestions... well, feature requests :-)

It would also be nice to have an option to turn off the blinking cursor
on the framebuffer.  With a full-screen boot logo as used on embedded
systems, even with a serial console or console on tty2, you still get
the blinking cursor in the top corner of the screen. (at least in 2.4.x)

Other options that might be useful, but less important: 
- Single logo option for SMP
- A "no logo" option, while still including framebuffer support
- Logo positioning (centered horizontally, vertically, both)
- Background and foreground text color options.  

A combination of these features would make it possible to do a smaller
logo (say, 256 x 128) centered on the screen with a matching background
color that would make it look like a full-screen logo, while not
bloating the kernel image much.

Also, some simple documentation that would help beginners do a
full-screen boot logo with the console on tty2 or serial should be
included with the kernel.  Lots of people want to use Linux on
"embedded" PC-based systems like kiosks, or just do this for fun on
their home computers, and doing this is confusing for beginners.

If you like, I would be happy to write documentation like this or help
in other ways.

I hope there is little resistance to merging a patch like this.  If
anyone doubts the need, I can only say that despite our patches not
being kept up to date regularly, I get a lot of email about them.  Also,
there are patches by other people to do things like this, some better
than others.  Despite the hassle of finding and applying these patches,
people want the feature badly enough to make the effort.  I see a lot
more desire for this feature than for many other worthwhile things that
are merged into the kernel...

Torrey Hoffman
tho...@ar...


On Wed, 2003-02-05 at 04:37, Geert Uytterhoeven wrote:
> On Tue, 28 Jan 2003, Geert Uytterhoeven wrote:
> > On Sun, 12 Jan 2003, Geert Uytterhoeven wrote:
> > > The current logo code is messy, complex, and inflexible. So I decided to
> > > rewrite it. My goals were:
> > >   - Logos must be accessible easily by an image editor (currently: hex C source
> > >     data must be converted to another format first)
> > >   - Logos must be stored in ASCII-form in the source tree
> > >   - Support arbitrary logo sizes (currently: fixed 80x80)
> > >   - Allow the logo to be selected statically (at compile time) and/or
> > >     dynamically (at run-time, based on machine type) (currently: at compile
> > >     time only).
> > >   - Allow simple adition of new logos
> > >   - Support grayscale logos (not used yet)
> > > 
> > > The patch achieves all of these. Logos are stored in ASCII PNM format in
> > > drivers/video/logo/, and automatically converted to hex C source arrays using
> > > scripts/pnmtologo. I chose ASCII PNM because (a) it's ASCII, (b) it's very
> > > simple to parse without an external library (XPM is more difficult to parse),
> > > and (c) it can be handled by many image manipulation programs.

[Linux-fbdev-devel] Re: fbcon scrolling madness + fbset corruption

[Russell K. <rm...@ar...>]

No one's commented on this yet.

James?

On Sun, Feb 02, 2003 at 07:57:44PM +0000, Russell King wrote:
> This doesn't appear to solve the ywrap problem - I still get
> places where the screen doesn't scroll.  I decided to write a
> small program to dump out the contents of fb_var_screeninfo, and
> where stuff goes horribly wrong:
> 
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+2352
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+2392
> 
> Up to the point where it goes wrong:
> 
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+528
> bash-2.04# ./tst
> Visible: 1280x1024
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+568
> bash-2.04# ./tst
> Visible: 1280x1024	<--- this is the last line on the screen
> Virtual: 1280x1632
> BPP    : 8
> Offset : +0+608
> bash-2.04#
> 
> So it looks like something isn't limiting the yoffset in the generic
> console layer; an xoffset of 2392 when the maximum virtual Y is 1632
> is just nonsense.
> 
> I also noticed an additional problem with fbcon: if I change the
> resolution using fbset, the change occurs, except I end up with
> corrupted mess on the screen (the reminents of the original display.)
> The shell prompt is nowhere to be seen.
> 
> Hitting ^L clears the screen and then the shell prompt is visiable.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Re: [PATCH]: image.depth fix to accomodate monochrome cards

[Geert U. <ge...@li...>]

On 8 Jan 2003, Antonino Daplas wrote:
> 1.  Changed meaning of image.depth.  If image.depth == 0, it flags for
> color expansion, otherwise, it flags for image drawing (without color
> expansion).  This change is to accomodate monochrome cards so they can
> differentiate character drawing from logo drawing.

What's the status of this issue? Monochrome is still broken due to this.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Christoph H. <hc...@in...>]

On Wed, Feb 05, 2003 at 01:37:44PM +0100, Geert Uytterhoeven wrote:
> > 
> > All comments are welcomed! Thanks!
> 
> Come on, is there really no one to comment on this??

Except a question why it's not merged yet? :)

Re: [Linux-fbdev-devel] Re: New logo code (fwd)

[Geert U. <ge...@li...>]

On Tue, 28 Jan 2003, Geert Uytterhoeven wrote:
> On Sun, 12 Jan 2003, Geert Uytterhoeven wrote:
> > The current logo code is messy, complex, and inflexible. So I decided to
> > rewrite it. My goals were:
> >   - Logos must be accessible easily by an image editor (currently: hex C source
> >     data must be converted to another format first)
> >   - Logos must be stored in ASCII-form in the source tree
> >   - Support arbitrary logo sizes (currently: fixed 80x80)
> >   - Allow the logo to be selected statically (at compile time) and/or
> >     dynamically (at run-time, based on machine type) (currently: at compile
> >     time only).
> >   - Allow simple adition of new logos
> >   - Support grayscale logos (not used yet)
> > 
> > The patch achieves all of these. Logos are stored in ASCII PNM format in
> > drivers/video/logo/, and automatically converted to hex C source arrays using
> > scripts/pnmtologo. I chose ASCII PNM because (a) it's ASCII, (b) it's very
> > simple to parse without an external library (XPM is more difficult to parse),
> > and (c) it can be handled by many image manipulation programs.
> > 
> > Code that wants to display a logo just calls fb_find_logo(), specifying the
> > wanted logo type, and receives a pointer to a suitable logo (or NULL).
> > 
> > I also modified fb_show_logo() to return the number of scanlines that are used
> > by the logo, so fbcon knows how many lines to reserve.
> 
> I put a new version at
> 
>     http://home.tvd.be/cr26864/Linux/fbdev/linux-logo-2.5.59.diff.bz2
> 
> Changes:
>   - Merge with 2.5.59
>   - New logo (CLUT224 only) for PA-RISC
>   - Let hgafb and newport_con include logo sources directly, since they need
>     access to the logos in non-init code
> 
> All comments are welcomed! Thanks!

Come on, is there really no one to comment on this??

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] writing to a floating point register ?

[Sven L. <lu...@dp...>]

On Wed, Feb 05, 2003 at 11:44:23AM +0100, Geert Uytterhoeven wrote:
> 
> Even if you could, it would work for 32-bit IEEE floating point format only.
> Is the hardware register format IEEE compatible.


Something like this :

unsigned long cfp32(unsigned long v, unsigned long d) {
        unsigned int x, vx, m, e;
        for (x=0, vx=v; vx>1; x++, vx>>=1);
        m = (x>22?v>>(x-22):v<<(22-x)) & 0x007fffff;
        e = ((x+127-d)<<23) & 0x7f800000;
        return (e | m);
}

Does the job. I don't really test for exponent overflow, but well,
anyone trying a video mode whose exponent is greater than 127 deserves
what gets.

Are there any other subtle things that may break with the above ?

Anyway thanks for your help.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] writing to a floating point register ?

[Sven L. <lu...@dp...>]

On Wed, Feb 05, 2003 at 11:44:23AM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Feb 2003, Sven Luther wrote:
> > On Wed, Feb 05, 2003 at 11:28:58AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 5 Feb 2003, Sven Luther wrote:
> > > > while writing a fbdev driver, i need to write a value to a floating
> > > > point register. Do we have any macro doing this, or should i need to
> > > > calculate the sign, mantissa and exponent by hand ?
> > > > 
> > > > Just doing a unsigned int cast would round the value i think, and thus
> > > > not give the right result.
> > > 
> > > You cannot use floating point math in the kernel.
> > > 
> > > What exactly are you trying to achieve?
> > 
> > Well, my framebuffer is not linear, and i have to enable a bypass unit
> > to fake a linear framebuffer. This bypass unit need that i write the
> > bytestride/64 32bit floating point value in a register.
> > 
> > for example : 1024 in 32 bpp => 4*1024/64 = 64.
> > 
> > 64 is 0100 0000 or 1.0 * 2^6.
> > 
> > So i have sign = 0, exp = 127+6=133 = 10000101, and mantissa = 0.
> > 
> > which gives 0100 0010 1000 0000 ... or 0x42 80 00 00.
> > 
> > I was hoping that i would not need to do this calculation by hand, but i
> > guess it is not possible, since like you said, we cannot use the FP
> > unit in the kernel.
> 
> Even if you could, it would work for 32-bit IEEE floating point format only.
> Is the hardware register format IEEE compatible.

Mmm, sure, didn't think of this. Would endianess and other such issue 
not be a problem for this kind of calculation ? Would it make sense to
have a special macro available for this kind of thing, like we have for
writing 8, 16 or 32 bits ?

> Anyway, the calculation is not that difficult.

Sure ...

> Perhaps you can even restrict line_length to be a multiple of 64 in all cases,
> in which case it's even made more easy?

Are all video modes we want to use multiples of 64 ? I guess yes.

> Does the hardware register allow denormalized numbers? Since you want to divide
> by 64 only, this would allow you to use a fixed exponent.

Erm, no idea, will need to try. That say, i don't know much about
floating point numbers, so i really don't know all that much about
denormalized numbers.

Mmm, i guess you mean that since we divide by 64, the mantissa would
always be 0 (1.000...) and we only need to write 127 + log2(value) in it
?  
Friendly,

Sven Luther

Re: [Linux-fbdev-devel] writing to a floating point register ?

[Geert U. <ge...@li...>]

On Wed, 5 Feb 2003, Sven Luther wrote:
> On Wed, Feb 05, 2003 at 11:28:58AM +0100, Geert Uytterhoeven wrote:
> > On Wed, 5 Feb 2003, Sven Luther wrote:
> > > while writing a fbdev driver, i need to write a value to a floating
> > > point register. Do we have any macro doing this, or should i need to
> > > calculate the sign, mantissa and exponent by hand ?
> > > 
> > > Just doing a unsigned int cast would round the value i think, and thus
> > > not give the right result.
> > 
> > You cannot use floating point math in the kernel.
> > 
> > What exactly are you trying to achieve?
> 
> Well, my framebuffer is not linear, and i have to enable a bypass unit
> to fake a linear framebuffer. This bypass unit need that i write the
> bytestride/64 32bit floating point value in a register.
> 
> for example : 1024 in 32 bpp => 4*1024/64 = 64.
> 
> 64 is 0100 0000 or 1.0 * 2^6.
> 
> So i have sign = 0, exp = 127+6=133 = 10000101, and mantissa = 0.
> 
> which gives 0100 0010 1000 0000 ... or 0x42 80 00 00.
> 
> I was hoping that i would not need to do this calculation by hand, but i
> guess it is not possible, since like you said, we cannot use the FP
> unit in the kernel.

Even if you could, it would work for 32-bit IEEE floating point format only.
Is the hardware register format IEEE compatible.

Anyway, the calculation is not that difficult.
Perhaps you can even restrict line_length to be a multiple of 64 in all cases,
in which case it's even made more easy?
Does the hardware register allow denormalized numbers? Since you want to divide
by 64 only, this would allow you to use a fixed exponent.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] writing to a floating point register ?

[Sven L. <lu...@dp...>]

On Wed, Feb 05, 2003 at 11:28:58AM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Feb 2003, Sven Luther wrote:
> > while writing a fbdev driver, i need to write a value to a floating
> > point register. Do we have any macro doing this, or should i need to
> > calculate the sign, mantissa and exponent by hand ?
> > 
> > Just doing a unsigned int cast would round the value i think, and thus
> > not give the right result.
> 
> You cannot use floating point math in the kernel.
> 
> What exactly are you trying to achieve?

Well, my framebuffer is not linear, and i have to enable a bypass unit
to fake a linear framebuffer. This bypass unit need that i write the
bytestride/64 32bit floating point value in a register.

for example : 1024 in 32 bpp => 4*1024/64 = 64.

64 is 0100 0000 or 1.0 * 2^6.

So i have sign = 0, exp = 127+6=133 = 10000101, and mantissa = 0.

which gives 0100 0010 1000 0000 ... or 0x42 80 00 00.

I was hoping that i would not need to do this calculation by hand, but i
guess it is not possible, since like you said, we cannot use the FP
unit in the kernel.

Or maybe there are some convenient macros available for that or
something ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] writing to a floating point register ?

[Geert U. <ge...@li...>]

On Wed, 5 Feb 2003, Sven Luther wrote:
> while writing a fbdev driver, i need to write a value to a floating
> point register. Do we have any macro doing this, or should i need to
> calculate the sign, mantissa and exponent by hand ?
> 
> Just doing a unsigned int cast would round the value i think, and thus
> not give the right result.

You cannot use floating point math in the kernel.

What exactly are you trying to achieve?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] writing to a floating point register ?

[Sven L. <lu...@dp...>]

Hello, ...

while writing a fbdev driver, i need to write a value to a floating
point register. Do we have any macro doing this, or should i need to
calculate the sign, mantissa and exponent by hand ?

Just doing a unsigned int cast would round the value i think, and thus
not give the right result.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Linux GUI considerations

[Fredrik N. <no...@no...>]

Hi,

> Almost none of the PDA manufatures considers Linux since it's almost
> impossible to bring anything nice on the screen.

I believe Sharp Zaurus SL-5600 runs Qt/Embedded on a framebuffer. I
haven't tested it myself, but there are some nice screen shots here:
http://www.trolltech.com/products/qtopia/screenshots.html

	Fredrik

[Linux-fbdev-devel] Linux GUI considerations

[Otto W. <ott...@bl...>]

Sorry for bringing this subject up here but IMO it's very important for
a better success of Linux (specifically for Linux on the desktop). And
IMO wxWindows is (or could be) one important component in helping
bringing more acceptance to Linux. Besides also wxWindows would profit
from a widespread Linux.

I fully agree with James Simmons when he complains about "Linux will
NEVER move into the desktop market!" (See
"http://www.kerneltraffic.org/kernel-traffic/kt20030131_203.html"). But
it's not only the free beer mentality or the missing jobs. It's also
because there is no pressure for any manufacture to invest at least a
minimum amount in Linux because not even home users are attracted by
Linux not to speak of business users.

Now why don't use everybody Linux if it's free? IMO one of the main
reason is there isn't a nice looking GUI and what's there is much too
complicate to set up. No end user (except "fanatics" like we) will ever
go through fixing an X configuration if it doesn't work right out of the
box which is much too much the case. And no end user will ever even look
at the console. No reseller will ever sell a machine with Linux to an
end user just because of these facts. Almost none of the PDA manufatures
considers Linux since it's almost impossible to bring anything nice on
the screen.

And what about the framebuffer alternative? While it might have the
potential to overcome the above obstacles, it's not even considered by
the vast majority of the current Linux user base itself. It's obvious to
anybody that the current framebuffer API isn't well suited as a base GUI
interface. Otherwise everybody would start using it, porting their
software to it. Even if it's done (like GTK 2.0) there is no use of the
framebuffer except as a base for an X server or a bigger console. Just
ask yourself, why isn't there already a framebuffer port in wxWindows?

What could be done to change this situation, especially what can the
wxWindows and the framebuffer people do? Since wxWindows has to draw its
controls on many different machines it's probably well known how an easy
to use interface of the underlying system should look like. And the
framebuffer people certainly know well how such an interface could be
implemented. So why don't sit some wxWindows guys together with some
framebuffer guys and try to work out a solution which suits both sides? 

Of course anybody of us has more than enough of his own tasks but it's
probably not asked too much about sharing its knowledge at least in
giving ideas or hints in which direction such a task should head. Also
to hear if this is altogether useless or if a successful solution could
be reached is welcomed. I'd be very pleased if some could be persuaded
into actually contributing anything, is it advice, knowledge or code.
IMO it's time that this task gets started.

What I'd like to know is what kind of API or functionality is necessary
for using it directly from wxWindows so a useful port could be
considered. Best would be if a specification or wish list could be
worked out which could be given to the framebuffer people for
consideration. They then might give feedback what can be done and how
much effort it'd need to implement. Or if there are other alternatives?

I'd like to keep this discussion here in the wx-dev mailing list (at
least for the start) but welcome any suggestions for a better place.

O. Wyss

[Linux-fbdev-devel] Re: fbcon scrolling madness + fbset corruption

[Russell K. <rm...@ar...>]

On Mon, Jan 20, 2003 at 09:29:38AM +0800, Antonino Daplas wrote:
> fb_pan_display() does not test for YWRAP.  Can you try this?

This doesn't appear to solve the ywrap problem - I still get
places where the screen doesn't scroll.  I decided to write a
small program to dump out the contents of fb_var_screeninfo, and
where stuff goes horribly wrong:

bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP    : 8
Offset : +0+2352
bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP    : 8
Offset : +0+2392

Up to the point where it goes wrong:

bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP    : 8
Offset : +0+528
bash-2.04# ./tst
Visible: 1280x1024
Virtual: 1280x1632
BPP    : 8
Offset : +0+568
bash-2.04# ./tst
Visible: 1280x1024	<--- this is the last line on the screen
Virtual: 1280x1632
BPP    : 8
Offset : +0+608
bash-2.04#

So it looks like something isn't limiting the yoffset in the generic
console layer; an xoffset of 2392 when the maximum virtual Y is 1632
is just nonsense.

I also noticed an additional problem with fbcon: if I change the
resolution using fbset, the change occurs, except I end up with
corrupted mess on the screen (the reminents of the original display.)
The shell prompt is nowhere to be seen.

Hitting ^L clears the screen and then the shell prompt is visiable.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Multiple rivafb devices?

[Fredrik N. <no...@no...>]

I have two Nvidia cards (one AGP and one PCI) and would like rivafb
to initialise both. I understand that currently isn't possible?

Would it be difficult to implement support for multiple cards?

Thanks,

	Fredrik

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[Antonino D. <ad...@po...>]

On Sat, 2003-02-01 at 23:45, Michel D=E4nzer wrote:
[snip]
> >=20
> > The fbdev driver will automatically load the DRM module when it refers
> > to any exportable symbol of DRM.  We can also make the fbdev drivers
> > specifically depend on DRM in Kconfig so users don't accidentally
> > compile fbdev without its DRM counterpart.
>=20
> I wonder if people will like having to build the DRM for a framebuffer
> device... a solution where one component uses the other if it's there,
> but works without it otherwise, might be better.
>=20
Yes, your suggestion is better.  I did browse the dri code, and my
feeling is drm is coded for userspace clients without any usable hooks
for clients residing in kernel space. I'm still wondering how to access
DRM services from kernel space. =20

> > The aim is not to avoid code duplication, although that is a plus, it's
> > two independent handlers clashing and locking up the machine.
>=20
> I'm not sure it would be that bad, but certainly suboptimal. :)
>=20

It will be bad.  The handler that gets loaded first will receive the
interrupt signal first.  It will, by necessity, clear the registers of
the event it's watching for to reenable the interrupt.  So when it's the
second handler's turn, and if it is also watching for the same event,
then it will falsely assume that the event never happened.  At worst,
the second handler will wait indefinitely for an event that will never
arrive, at best it will time out and send false information.

>=20
> > > Could it not be that the fbdev sort of minimally intialize the DRM wh=
en
> > > it is not already active ? After all, the fbdev knows as much, if not
> > > more, than the X driver about the graphic chips state, especially if =
the
> > > X driver is using the fbdev.
> >=20
> > I was wondering about this to.  How much initialization is required?  I=
s
> > it not enough to just load the DRM module?
>=20
> No. The DRM_INST_HANDLER ioctl needs to be called to make the IRQs work,
> and I suspect more needs to be done before that.
>=20

Yes, I also realized that.  My feeling is if James or Geert do agree to
add support for this, fbdev will just have to duplicate the code, taking
care that another handler may exist, or DRM will be rewritten so the
interrupt handling can be shared or made available to other modules, as
you suggested.

> > Also, we have fbdev drivers that are incompatible with DRM, so having
> > fbdev load DRM is like telling it to commit suicide :-)
>=20
> Out of curiosity, is that about i8xx?
>=20

No, the i810fb driver is compatible with X and DRM. =20

Tony

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[Michel <mi...@da...>]

On Sam, 2003-02-01 at 00:34, Antonino Daplas wrote: 
> On Sat, 2003-02-01 at 05:32, Sven Luther wrote:
> > On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel Dänzer wrote:
> > > On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > > > On Fri, 2003-01-31 at 19:24, Michel Dänzer wrote:
> > > > > 
> > > > > You don't need X to use the DRM, just some privileged client to
> > > > > initialize it.
> > > > 
> > > > You're right.  I just realized that since DRM already has an interrupt
> > > > handler, it is unwise for fbdev to install its own interrupt handler
> > > > too, as this will fatally lock up the machine when DRM and fbdev are
> > > > loaded simultaneously.
> > > > 
> > > > So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
> > > > drivers with a DRM counterpart, fbdev will just call the DRM
> > > > wait_vblank() and send_vbl_signals() functions.   Do you think this is
> > > > doable, I haven't examined the code thoroughly?  
> > > > 
> > > > The main goal is too avoid having 2 independent interrupt handlers for
> > > > one device.
> > > 
> > > A noble goal, but the framebuffer device would still need its own code
> > > when the DRM isn't active, so I'm afraid there's no way around code
> > > duplication, unless we could somehow factor out the common code for the
> > > two to share?
> 
> The fbdev driver will automatically load the DRM module when it refers
> to any exportable symbol of DRM.  We can also make the fbdev drivers
> specifically depend on DRM in Kconfig so users don't accidentally
> compile fbdev without its DRM counterpart.

I wonder if people will like having to build the DRM for a framebuffer
device... a solution where one component uses the other if it's there,
but works without it otherwise, might be better.

> The aim is not to avoid code duplication, although that is a plus, it's
> two independent handlers clashing and locking up the machine.

I'm not sure it would be that bad, but certainly suboptimal. :)


> > Could it not be that the fbdev sort of minimally intialize the DRM when
> > it is not already active ? After all, the fbdev knows as much, if not
> > more, than the X driver about the graphic chips state, especially if the
> > X driver is using the fbdev.
> 
> I was wondering about this to.  How much initialization is required?  Is
> it not enough to just load the DRM module?

No. The DRM_INST_HANDLER ioctl needs to be called to make the IRQs work,
and I suspect more needs to be done before that.

> Also, we have fbdev drivers that are incompatible with DRM, so having
> fbdev load DRM is like telling it to commit suicide :-)

Out of curiosity, is that about i8xx?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

Re: [Linux-fbdev-devel] Vertical retrace interrupts?

[Antonino D. <ad...@po...>]

On Sat, 2003-02-01 at 05:32, Sven Luther wrote:
> On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel D=E4nzer wrote:
> > On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > > On Fri, 2003-01-31 at 19:24, Michel D=E4nzer wrote:
> > > >=20
> > > > You don't need X to use the DRM, just some privileged client to
> > > > initialize it.
> > >=20
> > > You're right.  I just realized that since DRM already has an interrup=
t
> > > handler, it is unwise for fbdev to install its own interrupt handler
> > > too, as this will fatally lock up the machine when DRM and fbdev are
> > > loaded simultaneously.
> > >=20
> > > So, how about this?  Let fbdev have its own vblank ioctl, but for fbd=
ev
> > > drivers with a DRM counterpart, fbdev will just call the DRM
> > > wait_vblank() and send_vbl_signals() functions.   Do you think this i=
s
> > > doable, I haven't examined the code thoroughly? =20
> > >=20
> > > The main goal is too avoid having 2 independent interrupt handlers fo=
r
> > > one device.
> >=20
> > A noble goal, but the framebuffer device would still need its own code
> > when the DRM isn't active, so I'm afraid there's no way around code
> > duplication, unless we could somehow factor out the common code for the
> > two to share?

The fbdev driver will automatically load the DRM module when it refers
to any exportable symbol of DRM.  We can also make the fbdev drivers
specifically depend on DRM in Kconfig so users don't accidentally
compile fbdev without its DRM counterpart.

The aim is not to avoid code duplication, although that is a plus, it's
two independent handlers clashing and locking up the machine.

>=20
> Could it not be that the fbdev sort of minimally intialize the DRM when
> it is not already active ? After all, the fbdev knows as much, if not
> more, than the X driver about the graphic chips state, especially if the
> X driver is using the fbdev.
>=20

I was wondering about this to.  How much initialization is required?  Is
it not enough to just load the DRM module?

Also, we have fbdev drivers that are incompatible with DRM, so having
fbdev load DRM is like telling it to commit suicide :-)

Tony