neofb patches

Sorry I took a little while to get these out.. Had a bit busier weekend than I expected..

Attached are my patches for the neofb driver. All of these are against the 2.6.5 kernel. I'm still kinda new to the whole framebuffer subsystem, so if I've done something horribly wrong, let me know.

All of my testing has been against the Neomagic NM2200 (MagicMedia 256AV) chip in my laptop. I think all of these changes should be safe for other chips too, although it's possible a couple of the workarounds for bugs implemented here aren't necessary with some of the other chips and could be more carefully special-cased..

Anyway, the attached patches are as follows:

neofb.1.copyarea.patch - Fix copyarea positioning bug

It appears that the naming of the NEO_BC0_X_DEC and NEO_BC0_Y_*_DEC bitflags is wrong, or at the very least misleading, as their behavior is not as one would expect from the names. On the NM2200, NEO_BC0_X_DEC apparently enables both X and Y decrementing of addresses during a copy, so the positioning is relative to the lower right corner, not the upper right. I don't know exactly what the other flags do do, but they apparently don't affect Y decrementing, so the case where we were setting just these flags without NEO_BC0_X_DEC didn't work and corrupted the data while copying (are these flags perhaps used differently in later chips than in the 2200 I'm testing against?)

In any case, I didn't look into it horribly deeply, I just changed the routine to be a little less clever about what it tries to do (this is consistent with what the XFree86 driver does as well, and will hopefully work with all chips, whichever way they might treat these flags)

neofb.2.imageblit.patch - Fix imageblit for color images

It looks like the imageblit routine was written with only mono blits in mind. This patch adds support for color image transfers (Hi Tux!).

neofb.3.16bit.patch - Misc fixes for 16-bit mode

Changed the visual reported for 16-bit mode from DirectColor to TrueColor, since we don't support changing the colormap, which means we don't really support DirectColor. Also changed the palette entries for to be 32 bits wide even for 16-bit mode because this is what the logo code expects, and appears to be the correct way of doing things.

neofb.4.24bit.patch - Make 24-bit mode work

Added a couple of switch cases needed to make 24-bit mode actually work. The colormap setting code also needed to be moved to be after vgaHWRestore, so that the DAC would be configured properly (8-bit lookups) for 24-bit color before writing to the lookup table.

Also, it looks like there's a hardware bug with the NM2200 if you try to do a color-expanded transfer in 24-bit mode and the width of the image is less than 16 pixels wide (The left few pixels of the image seem to get partially wrapped onto the right side. I haven't tested all cases, actually.. I know it breaks with 8-pixel-width blits), so in that case we just fall back to cfb_imageblit instead.

Actually, the imageblit bug could conceivably be there with color transfers too, I haven't tried it. Would require something trying to imageblit a 8-pixel-wide 24-bit image, in 24-bit mode. I suspect the bug is probably related to the source-data width in bits and/or the hardware mono->color translation, though, and in either case this wouldn't be an issue for 24-bit color.

neofb.5.modedb.patch - Change to use modedb for video mode selection

Allows specifying the video mode on the kernel/insmod command line now too.

I have also attached an additional patch which is mostly, but not quite entirely, complete. I thought it was working until I was packaging all of this up and discovered that it's actually intermittent. If anybody has suggestions for what's missing, please let me know:

neofb.6.blanking.patch - Add support for DPMS blanking

I just copied the logic from the XFree86 driver to add DPMS support. This currently works for me some of the time and doesn't other times, and I'm still tracking down why. It looks like I probably need to do something more in the initialization stage to turn on this functionality properly (I note that there are a _lot_ of registers which the BIOS and the XFree86 driver have values set for which show up as zero under the neofb driver. I'm guessing this is part of the problem.)

(Oh, and I also changed the wording of the comments at the beginning of things to make a bit more sense in this context. Between an unfortunate renaming one of the function parameters and the fact that the comments were copied from a different part of the code (and thus speak from a different perspective), these comments were initially very confusing to read. Hopefully now they are somewhat less so.)

I'm also still looking into a couple of minor "annoyance" bugs, but these patches fix most of the real functionality deficiencies I've found so far (or will, once I figure out why blanking is buggy.. grumble)..

Feedback is welcome.

-alex

@@ -1367,18 +1367,13 @@
 
 	bltCntl = NEO_BC3_FIFO_EN | NEO_BC3_SKIP_MAPPING | 0x0C0000;
 
-	if (sy < dy) {
-		sy += (area->height - 1);
-		dy += (area->height - 1);
-
-		bltCntl |= NEO_BC0_DST_Y_DEC | NEO_BC0_SRC_Y_DEC;
-	}
-
-	if (area->sx < area->dx) {
+	if ((sy < dy) || (sy == dy && sx < dx)) {
 		sx += (area->width - 1);
 		dx += (area->width - 1);
+		sy += (area->height - 1);
+		dy += (area->height - 1);
 
-		bltCntl |= NEO_BC0_X_DEC;
+		bltCntl |= NEO_BC0_DST_Y_DEC | NEO_BC0_SRC_Y_DEC | NEO_BC0_X_DEC;
 	}
 
 	src = sx * (info->var.bits_per_pixel >> 3) + sy*info->fix.line_length;

@@ -1394,9 +1394,23 @@
 neo2200_imageblit(struct fb_info *info, const struct fb_image *image)
 {
 	struct neofb_par *par = (struct neofb_par *) info->par;
+	int bltCntl_flags, data_len;
 
 	neo2200_sync(info);
 
+	if (image->depth == 1) {
+		bltCntl_flags = NEO_BC0_SRC_MONO;
+		data_len = (image->width * image->height) >> 3;
+	} else if (image->depth == info->var.bits_per_pixel) {
+		bltCntl_flags = 0;
+		data_len = (image->width * image->height) *
+		    (info->var.bits_per_pixel >> 3);
+	} else {
+		/* We don't currently support hardware acceleration if image
+		 * depth is different from display */
+		return cfb_imageblit(info, image);
+	}
+
 	switch (info->var.bits_per_pixel) {
 	case 8:
 		par->neo2200->fgColor = image->fg_color;

@@ -1411,7 +1425,7 @@
 	}
 
 	par->neo2200->bltCntl = NEO_BC0_SYS_TO_VID |
-	    NEO_BC0_SRC_MONO | NEO_BC3_SKIP_MAPPING |
+	    NEO_BC3_SKIP_MAPPING | bltCntl_flags |
 	    //                      NEO_BC3_DST_XY_ADDR |
 	    0x0c0000;
 

@@ -1424,7 +1438,7 @@
 	    (image->height << 16) | (image->width & 0xffff);
 
 	memcpy(par->mmio_vbase + 0x100000, image->data,
-	       (image->width * image->height) >> 3);
+	       data_len);
 }
 
 static void

@@ -952,8 +952,10 @@
 		info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
 		break;
 	case 16:
-		/* DirectColor, 64k */
-		info->fix.visual = FB_VISUAL_DIRECTCOLOR;
+		/* TrueColor, 64k */
+		/* Note, this is NOT DirectColor, because we don't support
+		 * setting the hardware colormap. */
+		info->fix.visual = FB_VISUAL_TRUECOLOR;
 
 		for (i = 0; i < 64; i++) {
 			outb(i, 0x3c8);

@@ -1240,7 +1242,7 @@
 		break;
 	case 16:
 		if (regno < 16)
-			((u16 *) fb->pseudo_palette)[regno] =
+			((u32 *) fb->pseudo_palette)[regno] =
 			    ((red & 0xf800)) | ((green & 0xfc00) >> 5) |
 			    ((blue & 0xf800) >> 11);
 		break;

@@ -1348,7 +1350,7 @@
 		break;
 	case 16:
 		par->neo2200->fgColor =
-		    ((u16 *) (info->pseudo_palette))[rect->color];
+		    ((u32 *) (info->pseudo_palette))[rect->color];
 		break;
 	}
 

@@ -1418,9 +1420,9 @@
 		break;
 	case 16:
 		par->neo2200->fgColor =
-		    ((u16 *) (info->pseudo_palette))[image->fg_color];
+		    ((u32 *) (info->pseudo_palette))[image->fg_color];
 		par->neo2200->bgColor =
-		    ((u16 *) (info->pseudo_palette))[image->bg_color];
+		    ((u32 *) (info->pseudo_palette))[image->bg_color];
 		break;
 	}
 

@@ -177,6 +177,8 @@
   int internal_display;
   int external_display;
   int libretto;
+
+  const struct fb_videomode *default_videomode;
 };
 
 typedef struct {

I have the same chipset. I have the new driver posted at my website. I tried your patchs but I had no luck.

Yeap. Really bad bug. I fixed it in the new driver.

I tried this patch. My boot wouldn't boot with this patch. Mind you I never got the imageblit to work right.

I haven't tried this one yet. Geert is this right?

This can be handled by struct fb_pixmap. It padded image scan_lines to what the hardware can handle or is optimized to.

Also barfed my machine :-( I really like to get i2c support going. Perhaps we should ask neomagic for the full specs for this chipset.

Ug. The new neofb driver has been moved over to use the new vga core code. See vgastate.c and vga.h in include/video.

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

I wasn't aware of your patches earlier (or where to get them).. I found the URL you posted in another message and have just downloaded the diff and will look into integrating things..

What is your LCD resolution, BTW?

Could you be a little more specific?

Were you applying this to a stock kernel or to your patched driver? What exactly happened when you tried it? You were booting in 8-bit color mode, I assume?

Ok, I'll take a look at this.. I was planning on going back and investigating this further anyway. Initially I was just concentrating on getting working functionality.

Hmm.. again, what does "barfed" mean, exactly? Did you try specifying different video modes on the command line?

Ah, ok.. I'll make the appropriate adjustments.

-alex

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

1024x768. Its a IBM thinkpad 600X.

Patched driver. I manually applied your patches. I start in 8 bpp mode. Nothing appeared on the screen.

Okay. Cool We can work on a solution for this problem.

Blank screen.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Well, I downloaded your diff for the neofb driver and tried it out. I did notice there appears to be a slight bug in it. Whenever anything (such as fbset) closes /dev/fb0, the driver clobbers the device registers (resulting in a blank screen).

I'm assuming the attached correction is more what was intended..

I'm currently merging our two sets of patches into one driver. I do note that patch gets a little confused when trying to do it itself and places a couple of bits of code in really odd places, which might have been part of why it didn't work for you. I think I should have an updated patchset ready to post later tonight..

-alex

@@ -562,7 +562,7 @@
 	struct neofb_par *par = (struct neofb_par *) info->par;
 	int cnt = atomic_read(&par->ref_count);
 
-	if (cnt) {
+	if (!cnt) {
 		memset(&par->state, 0, sizeof(struct vgastate));
 		par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS;
 		save_vga(&par->state);

Ok, I've got everything except the blanking patch (which isn't finished anyway) converted to apply cleanly to James' patched driver source. Everything works fine on my laptop as far as I can tell. Additional feedback is welcome.

I've put up a web page for the patches. They can be found at
http://www.foogod.com/~alex/neofb/

-alex

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Got it. I merged your patches. I also did a few fixes. The code had issues with non byte align images, i.e sparc 12x22 fonts. Now it works. I posted at

http://phoenix.infradead.org:~/jsimmons/neofb.diff.gz

This is against the latest kernel.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

On Sat, 24 Apr 2004 00:00:23 +0100 (BST) James Simmons <[email protected]> wrote:

| 
| > Ok, I've got everything except the blanking patch (which isn't finished
| > anyway) converted to apply cleanly to James' patched driver source. 
| > Everything works fine on my laptop as far as I can tell.  Additional
| > feedback is welcome.
| > 
| > I've put up a web page for the patches.  They can be found at
| > http://www.foogod.com/~alex/neofb/
| 
| Got it. I merged your patches. I also did a few fixes. The code had issues 
| with non byte align images, i.e sparc 12x22 fonts. Now it works. I posted 
| at
| 
| http://phoenix.infradead.org:~/jsimmons/neofb.diff.gz
| 
| This is against the latest kernel.

Hi James,

I think it would help a bit if someone could load
http://phoenix.infradead.org/~jsimmons/ in a web browser and be able to see a list of files/patches/etc there instead of having to know an exact file name to grab.

--
~Randy

Well, since he only seems to have one patch available at any given time, this doesn't seem like that big a deal to me, personally.. I was, however, thinking of suggesting that it might be easier to keep track of things if there were some sort of version numbers or datestamps or something in the filename so somebody can tell that this "neofb.diff.gz" is actually a different patch from the "neofb.diff.gz" that was in exactly the same place yesterday..

-alex

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Okay. I can add a date stamp on it.

Your right. I have to wipe up a web page for that.

Umm, I would really appreciate it if you didn't silently leave out bits of my patches and then just say "I merged your patches". It took me a little bit to figure out that the reason panning now isn't used for fbconsole scrolls is because you just didn't bother to put that part of my patch in.

Is there some reason you left out the following piece of my modedb patch?

+       /* Turn on panning for console scroll by default */
+       info->var.yres_virtual = 30000;
+       info->var.accel_flags |= FB_ACCELF_TEXT;
+       if (neofb_check_var(&info->var, info))

+ goto err_map_video;

-alex

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Actually, look more closely at that code. That is _unsetting_ FB_ACCEL_TEXT under some circumstances, but under the current new code it never actually gets set anywhere. I originally had my code your way, but then needed to add the extra bit above to get ypanning to actually work.

yres_virtual does need to be set larger than yres in order for ypanning to function, last I checked. In order to set it to the correct value for the particular card, we set it to 30000 (very large), and then call check_var to have it scale it down to what the hardware can handle (this seems cleaner to me than duplicating the code to properly size things in two routines). This must be done after the correct video mode is found by fb_find_mode, however. We could have set FB_ACCEL_TEXT earlier, but I put it in the same place for clarity.

We probably should change that to a "> 24" yeah (or maybe just get rid of it all together).. I hadn't caught that before. I haven't actually tested it at 24-bit but I don't see why it shouldn't work.

-alex

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Your right. I need to reverse that logic.

Yipes!!!!! You found a nasty bug in modedb. The present modedb code sets both xres/xres_virtual to the same value and yres/yres_virtual to the same value. This means any driver that uses modedb automatically turns off panning. This is bad.

The new test I purpose is

if (par->neo2200 && var->bits_per_pixel != 32)

	var->accel_flags = FB_ACCELF_TEXT;

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Heh.. and here I thought that was intentional (I assumed it was because some drivers (which don't support panning) might balk at a perfectly valid mode if the virtual and actual numbers weren't the same). I had rather assumed that other drivers worked around it like I did :)

Actually, since we don't have any way currently to get var->bits_per_pixel == 32 (and the driver would need a lot of work to get to that point at which point this case could (and should) actually be tested instead of just assuming it doesn't work), why don't we just simplify it to:

if (par->neo2200)

	var->accel_flags = FB_ACCELF_TEXT;

I've never been too clear on what direction these FB_ACCELF things (and related values) are supposed to be going. Are they something set by the driver to indicate what it can support, or are they something set by the higher level systems (or the user) to tell the driver what they would like to do?

I had figured from the previous code that these flags should be set when calling check_var if the higher-level stuff wanted acceleration for the particular mode setting, and the driver would unset any it wasn't able to support. This changes the behavior to automatically turning it on whenever the hardware is capable of it, regardless of what the higher level stuff asks for (which is actually probably a better protocol, but is it the way all the other stuff is expecting it to work?).

Actually, in any case, the current code is still more correct than the proposed code above. Under the proposed code, if something sets FB_ACCELF_TEXT, then calls check_var, FB_ACCELF_TEXT will stay set even if the hardware can't do it. We should probably keep the old test in there too to prevent this case.

Howabout:

if (par->neo2200)

	var->accel_flags = FB_ACCELF_TEXT;
else
	var->accel_flags = 0;

-alex

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

It's used to indicate that the frame buffer device uses hardware acceleration for rectangle fill/copy and imageblit.

It must be explicitly disabled before a user space application can mmap the MMIO registers to do its own hardware acceleration, to avoid accelerator access conflicts.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

I think we should stick to KD_TEXT/KD_GRAPHICS for who owns the engine.

I don't think fbdev should expose any "acclerated" API to userland, that is a hopeless goal and will lead to nothing. We need some arbitration layer at one point between whatever accel stuff we use (DRI, userland accel library) and somebody changing mode though. Lots of stuffs I've tried to figure out and didn't end up with anything reasonable yet, lack of time doesn't help...

Ben.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

I wouldn't bank on that. I seen this solution fall short. Consider a system where we have a serial console, vgacon, and fbcon (say hgafb). Well I leave it to the imagination what can go wrong.

I agree we need arbitration. Eventually fbdev and dri have to merge. Mode setting is still best handled kernel side. That is just a reality.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

I can see how vgacon and fbcon would walk all over each other but how would a serial console mess things up?

Arbitration would be best. How would it be done generally? Some mechanism that arbitrates based on mem/io ranges or something else?

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Same question... Where is the problem ?

We need several level of arbitration, I'm not sure hwo to do that at this point and I don't have time to dive into the DRI side of things.

Jon Smirl has been working on embedded mesa & moving DRI outside of X. Unfortunately, last I heard, he was still on his trip of re-inventing everything including replacing the fbdev's with his own stuff instead of moving from what we have ...

Ben,

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Say two people are logged in. One on a serial console and another on the framebuffer console. The person starts X fbdev from the serial console. Ooops the fbcon user lost his console.

Ug. This is sad :-(

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

And ? Where is the problem ? I can do that today with ssh ... That's normal console switch. X will trigger a console switch to a new VT, it will not just tap on the current console "as is".

Benjamin Herrenschmidt <[email protected]>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

That's another thing I'm adding to my kernel. I didn't mention it as I'm still trying to nail down a few details. My current experiment is that I've made device number 5,255 for now (later I'm either going to make it 5,0 or just make fb0 point to it but that's one of the things I'm debating) and call it just fb (for now). Now when a user opens this fb it will figure out what console they're on and refuse to run if it's they're not on a physical console (unless fbcon is not compiled then it will default to fb0 - these are the details I'm working on).

Now if the user really wants to start something from a serial console or even a ssh session for that matter they can just use an explicit frame buffer device like fb0, fb1, etc. These would then be root only for example.

An added bonus is that if you have multiple video cards or a dual head configuration with each head on a different fbx device the 5,255 device would figure out which console you are on when you start the program and use the appropriate fb device. Once the radeon dual head code gets written I'll have to try to start X on fb0 (head 1) and leave the fbcon running on fb1 (head two).

But this is just a fun little experiment on my part. If I succeed I'll let everyone know.

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Hrm... I'm not fully confortable with this. I don't see why we need anything different but what we had today.

Nah, software like X, MacOnLinux, etc... should open a VT and trigger a console switch. Or at least switch to KD_GRAPHICS if they don't, but then, having a user doing that to your console is only a matter of setting the proper permissions. Again, I don't see what problem you are trying to solve.

Benjamin Herrenschmidt <[email protected]>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

For stuff like X, MacOnLinux, etc that totally take over it doesn't make too much sense. But for framebuffer programs like picture viewers, movie players, games, and other non desktop single purpose applications it makes a lot of sense.

For example lets say I have odd numbered consoles mapped on my AGP Radeon card and even numbered consoles mapped to my PCI Riva card. I switch to console 1 and fire up a fb dvd player app. It opens /dev/fb (29,255) and switches to KD_GRAPHICS. LOTR starts playing on my big 21" monitor hooked up to the Radeon. As a user I didn't have to know that /dev/fb0 was really my 21" monitor and didn't have to give any command line switches to do this. The cursor was blinking on my 21" and all I had to do is type dvdplay and away I went. I would also be prevented from switching to odd numbered consoles now.

No problem. ALT-F2 and now my 19" monitor has a blinking cursor. I type in picview and again the jpeg viewing program opens /dev/fb and switches to KD_GRAPHICS and now I'm looking a vacation photos on my old riva card. Again, I didn't have to know that /dev/fb1 is my 19" monitor and no command line arguments. The app fires up on the monitor that had the focus (forground console doesn't sound right on multi monitor setups IMHO).

Now I can only switch between console 1 and 2. Consoles 3 and up can't be switched to as both fb devices are in use.

BTW, this is just an example. I don't know if a fb dvd player is out there but I do belive there's a picture viewing fb app.

Normally yes. But let's say a switch was added to X or X's fb driver to tell it to not open a new VT and just start on the current console. If I fire it up on console 1 X starts on my 21" monitor but if I start it on console 2 it fires up on my 19" monitor. The other monitor would still have a console.

This was just a fun thought to see if it would actually work. But the dvd/picture example above is very practical.

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Why ? Your player doesn't support proper console switching ?

You don't need a /dev/fb for that do you ? You need to map the current vt to it's fb via the existing fbdev ioctls, isn't that possible ? (just asking , I've never actually done that).

Yup, but I don't think we need to change much of the actual code to acheive this result. We still have the KD_GRAPHICS/KD_TEXT thing for arbitrating who owns the accel engine and it would just work.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

But how does the app find this out? It would have to figure out if it's running on a real console then figure out which console is mapped to which fb and then try to find out which /dev/fbx device points to that fb. Programmer's are lazy, they'll just make it a command line switch to specify what device to use which is not very user friendly.

What I'm proposing is that you open /dev/fb. If it fails you're running on a serial line or shh or whatever. If it succedes you issue KD_GRAPHICS ioctl on the /dev/fb device and that's it. Very simple for the programmer.

The kernel does all the work. It figures out what vt you're on and prevents access from serial or a pty. It also would figure out which framebuffer device to connect to based on the con2fb map specified by the fbdev ioctls. It would pass the KD_TEXT/KD_GRAPHICS calls to the appropriate vt.

This makes it very user friendly. The user just switches to the vt that's on the moitor they want and starts the app. The kernel figures out how to route this to the appropriate fb driver according to the con2fb map.

I might also be possible to use /dev/tty as the starting point if you want to make everything start at the vt layer and work down. The fb ioctls would just have to be passed down. Once a KD_GRAPHICS was issued on /dev/tty then read/write/mmap would pass down to the fb layer as well.

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I like the idea of having graphical apps automatically open on the same framebuffer device as the console they were started from, but I agree with Ben, I think this approach is way more complicated than it needs to be.

Firstly, all of the graphical apps you're describing should be VT-aware. If they aren't, you shouldn't be using them on anything other than dedicated framebuffers anyway, really. It's not hard to make an app work with VTs and it really is the correct way to do things for anything that is likely to be run in a VT-console environment.

With this issue solved, all that needs to be done is to make it so that apps which open up a new VT, automatically get it on the same framebuffer as the currently active console (or better yet, the console associated with the app) is on (which is really the most intuitive thing anyway, and should probably be done on general principle). Problem solved.

You really don't need all the complex machinations of a magic /dev/fb device to achieve this. If the rest of the system is designed well the right behavior should be automatic without this extra effort.

-alex

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

A good idea would be to produce a library that implement most of the ground VT handling work in fact... That would simplify things for apps tremendously. Though it should probably sit between the app and the kernel for console input as well.

It would basically callback into the app for things like beeing swithout out and back in.

Benjamin Herrenschmidt <[email protected]>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

That would be nice. The only problem is history has shown that lots of people think the library should be done one way verses another and we need up with lots of libraries.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I don't believe it will be complicated but I'll find out after I try to implement it. I just like the fact the the kernel would be able to keep applications from doing silly things. Hey, if it turns out to be an ugly patch I'll be the first to delete it. Who knows, parts of it might be useful. And it's a great way for me to learn more of the innards of the vt/fb systems.

Hmm, I'll have to do some hunting. What is the easy way to find out if you're on a physical console and what vc num it is in user space? I can do it easily in kernel space...

That might be tricky as you'd probably have to change the con2fb map to remap the unused console to the right fb.

Unfortunately it's not automatic. The programmer has to jump through a few hoops that it would take a couple of dozen lines of code in kernel space to do. This is just off the top of my head so it's probably not entirely correct:

if( fbidx == 255 ) {
if( current->tty->driver != console_driver )

      return -ENODEV;

fbidx = con2fb_map[ current->tty->index ];
}

Add another dozen lines to do the the KD_TEXT/KD_GRAPHICS and that's 90% of the functionality of the /dev/fb device.

Like I said, it's just a small experiment on my part. Maybe someone will find it useful or maybe they'll get some other ideas from it. The only reason I haven't tried it yet is I have to hunt down where my PCI video card disappeared to so I can try it on a dual fb setup.

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Umm, the point is you don't have to. Just create a new VT for whatever you're doing. If you have permission to do it, you will get a VT you can work with. If you don't, you'll get an error. Ultimately, it shouldn't matter whether you're being started from a VT to begin with anyway (a user _should_ be able to login via ssh or serial console or whatever and start up a framebuffer app if they want to and have the permissions to. This is one of the fundamental principles of unix (the user knows what they want to do better than the OS does. The OS shouldn't get in the way of that.)). If a different user is currently using the framebuffer for their console (or app or whatever), the permissions should be set to protect it, otherwise it's fair game.

Actually, no, the point I was making is that we should change the VT/console code to automatically copy the "current" mapping to a new VT when it gets created, so you don't need to remap anything for this case.

Basically what I'm suggesting pretty much the same thing you are, I'm just saying we should do it with the existing VT infrastructure instead of creating a new /dev/fb for what's basically a very similar thing to what VT is already supposed to handle more generally (controlling which screens consoles/apps access and when).

-alex

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Depends on how you look at it. If a user is on console 1 and starts a simple app (not a desktop environment) having that jump to console 9 is a little confusing. And there are only so many function keys. Several X sessions will eat up the remaining function keys. Once all the function keys are used then it becomes a royal pain switching VTs.

As for not mattering whether you're being started from a VT, I'm on the other side of the fence here. When I ssh into a machine, the text apears on my local maching and not on the remote. Same goes for the terminal bell and led status. And when you run an X app the display is local as well. Now the framebuffer breaks away from that. When I fire up a framebuffer app the output doesn't appear locally but on the remote machine. Now I agree that the system shouldn't stop someone from doing this if they really want to. That's why the fb0, fb1, etc devices wouldn't stop you running them remote and would have the stricter permissions on them (root only for example).

Besides, the person that stole my console from under me remotely would be in a world of hurt once I got back into my machine. :)

We're both saying the same thing. When I said "remap" I meant telling fbcon to assign a particular framebuffer to that console.

Pretty much. The only differences are is that I want the app to always stay on the same VT number and that the programmer only have to deal with one interface. Why should every frame buffer program be required to carry extra VT code and most programmers will be too lazy or won't know how to include it. Even fbtest doesn't have any VT code in it. With the code in the kernel even legacy apps will start using the new correct behaviour.

John

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

So you break the virtualization layer of the VTs. I still want to be able to switch to consoles 3 and up.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Nope, nothing is broken. The limitation is the fb application. If the app using the framebuffer knows how to handle being switched away from (releasing the fb after getting the switch away signal and reacquiring the fb and repainting when getting the switch to signal) then switching to the other consoles would work.

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I was wondering if it is possible currently (kernel 2.6.5) to have 2 differents video cards in 2 differents VCs and in 2 differents fbdev's. I have an old trident pci card and one radeon agp card. I want to run X (Xfbdev) in the trident one and mesa-solo in the radeon one, is that possible? how?

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Yes, I've tried that in 2.5.x, assuming nothing broke in between. You need a utility to map which console to which fbdev (con2fbmap?). However, you can't use them simultaneously (switching to one console inactivates the other), that's for the ruby project.

Tony

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I have written a graphics server that scans for video cards (via libHAL from fd.o) and spawns a thread for each card, I have the support in place for differents cards (with multi-desktops or Xinerama like in the same box). All I want to acomplish is to have 2 (or more) differents fbdevs rendering to different monitors in the same time. Currently my server enables DRI (old mesa-solo) for supported cards (mostly AGP ones) or mesa-fbdev for unaccelerated ones. The problem is that without X i can access only the primary card (the one set it up in the bios) but if i try to load the fbdev module for the second card it simply will not work.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

That's what I'm currently working on and is partially what's behind my messages about multiple vars and whatnot. It looks like most of the stuff is already in the kernel. I'm just going through the various subsystems trying to figure out what still needs to be changed. One things is the the vt driver's notion of which vt is visible. Currently that's fg_console == visible but with multiple monitors that doesn't hold true.

I'll post when I succeed. :)

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

What your doing is alot of work. Trust me because I already have reworked the VT layer to support multiple terminals. Its more than fixing fg_console.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

User logged in from serial console should not be a member of the 'video' group. PAM solved that a while ago with /etc/security/group.conf assuming a well configured box.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Ooops! that will break my software that relies on fbdev and mesa-solo!

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Well, I'm sure there is some good in what he is doing too, I don't have time to deal with that at the moment, it would be interesting to synchronise properly though.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Yea, I remember he was trying to solve the very same problems I currently have now. I like the fbdev abstraction but it has too many limitations:

- Improper video mode handling. Simply the device driver should hint about valid modes, EDID, etc.
- When an app crashes the layer is unable to recover it's previous state even when proper semantics exist (KD_TEXT/GRAPH), when the kernel closes the fbdev it must trigger a return to KD_TEXT if in KD_GRAPHICS and set the fix and var settings remembering that settings before leaving KD_TEXT.
- It should exist a field in the fixed info for the bus_id, so intelligent apps will realize which card is attached to a fbdev.
- Cards with various display ports must be handled by the layer, with a new API just to handle ports.
- It dangerously coexists currently with the DRM queues and SAREA areas. Both must merge in fbdev.
- VCs mess.
- Wasted effort in accel engines handling is only useful to fbcon, nobody needs acceleration to drive a X x Y character matrix in fbcon. The argument that hw without a framebuffer will exist and that's why the accel engine must be used is BS, the PC, the BIOS and the video framebuffers will never die, framebuffer exists in the best video cards money can buy today and it exists in planned cards from major manufacturers for tomorrow, probably the framebuffer can't be accessed when the accel engine is being used in forthcoming cards but that is completely a different story.

IMHO this must be addressed ASAP if we want to compete with Longhorn and MacOSX. People should realize that fbdev is a linux standard that needs to be modernized and it must be fixed, we should not devote more resources to implement complex accel engines in the fbdev drivers, acceleration has it's place in userspace layers like DirectFB or DRI (mesa-solo), not in the kernel where a light, simple and elegant solution for graphics should exists.

I now understand why Jon Smirl took that hard but neccesary path. Even if we start this for 2.7 it will be too late as linux 2.8/3.0 will ship 2-3 years late.

C'mon James, Ben, Geert, driver writers, let's fix the layer!

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Should be fixed soon with sysfs in 2.6.

Time, time, time...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

[...]

How does a DRM SAREA matter to a framebuffer device?

I agree that they should cooperate properly, but I don't see how it follows that they must merge.

Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

It matters as long as the SAREA have a hardware lock to synchronize access to the hardware. That lock must be owned by a single entity in the kernel, or at least the fbdev drivers must be aware of that lock, it would be more simple if the fbdev drivers take care of it being the single entity in the kernel taking care of the hardware.

DRM and fbdev must merge so i repeat: just a single kernel entity should own FIFO queues, shared locks, DMA, the framebuffer, IO registers, interrupts, etc.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I agree. That is why I create a par abstraction in fbdev. The idea is dri and fbdev coudl share the same core data structure.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Why? The purpose of the DRM lock is arbitration and state management between DRM clients. It's not necessarily connected to direct hardware access.

Jon Smirl thinks it should be the DRM...

A small low-level driver could handle this, which both the framebuffer device and the DRM use. Linus has proposed this approach, and I must say I like it.

Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

The idea here is to have a small per-card low level driver (no common API or little of it) used to do the IRQ, fifo/ring management & blasting of registers. Everything else is client of this driver, including possibly fbcon. That also means we move all of mode management to userland, which I tend to slowly agree with. Remember that in 2.7, we may have an initramfs with klibc etc... thus we can have userland code shipping along with the kernel.

I started working on a userland API do deal with all of the mode management cruft that could be implemented either on top of fbdev or something else, but I didn't have time to finish. And I think Jon Smirl started his own different thing (of course) there...

One of the ideas we had after discussing with Keith Packard that the model should be a library that deals with all the settings of the displays, the geometry of the desktop(s) (relative position of screens), modes, etc... That library would interface to the various drivers via backend libraries and would broadcast via dbus the environment changes so that things like window managers, x servers, or whatever else can adapt. Applications would talk directly to the library.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Wow!!!!! Linux is going to end up a micro kernel after all. We could move the tcp stack and even all the filesystems to userland as well. The kernel will shrink to such a small size. Then bus setup could be done in userland. All we need to do is setup the cpu. No more device drivers.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

The fbdev is low-level, i vote for fbdev to be the single entity for graphics in linux.

I would like to see that basic stuff being done in the kernel like mode setting. The drivers should have a better idea of modes than libraries in userspace.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Not really. The driver can extract the EDID infos from the card, but as far as building mode lists, at one point, we really want that to be moved down to userspace. One of the problems is that a lot of monitors have bogus EDID blocks. We need a mecanism to provide "overrides" based on manufacturer/product ID for example, I don't think it's something that should be in the kernel.

Also, for something like dbus notification of clients, userspace is better suited.

Finally, the geometry of screens is something that has nothing to do in the kernel imho.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I agree. Mode setting is one of those things you have to do kernel side.

We already have such things in the kernel. DMI blacklist in the kernel on the x86 platform. Also we have PCI fixups in the kernel. Should we move those to userland as well. Now if you believe in a micro kernel design then that is a yes. In struct fb_monspecs we have a monitor identity field. So we can deal with this. Also if we have a corrupt EDID block then we can default to using the default modedb. Its not a hard problem.

I don't like micro kernel designs. This is way micro kernels handle this problem.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

This has nothing to do with microkernel design and everything to do with not bloating the kernel with things that don't to be there.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I would like the kernel to handle CRTCs and overlays in the same way, and that way IMHO should be to calculate register values in userspace and just have a few ioctls to have the kernel write them.

Set all registers ioctl:
Nothing special needed here I think.

Set buffer offset (pan/flip) ioctl:
This one should return the current vertical blank counter. It's needed for proper triple buffering. It should also be able to choose when to flip (immediately or vblank, on top/bottom/any field).

Wait for vertical blank ioctl:
This one should also return the current vblank counter. It should also be able to wait for absolute and relative vblank counter values. Waiting for relative=1 would insure you're at the vblank when it returns and waiting for absolute=last_flip_counter_value+1 would help with double buffering.

The main reason for userspace register calculation is that there are a lot of knobs in some hardware (especially with overlays). Trying to abstract those without loosing any features would be a problem. And even the API would cover all of todays graphics chip something new might come along in the future and the API might become too limited.

Ville Syrjälä
[email protected]
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id�66&op=click

Reason why a "universal" library will not work.

1) There will never be a universal library. I have worked with:

EmbeddedQT
framebuffer based Gtk
directfb
sdl
Embedded OpenGL
GGI
Java j2me
lots of home brewed solutions

The latest thing now is OpenML. Next year it will be something else.

Ben you can create your library all you want but the reality is very few will end up using it.

2) Several of the above libraries depend on mode changing being avaliable in fbdev. Take that away and alot of companies will be very upset. I tell you if I owned/worked for a company that wrote embedded software that changed the video mode via fbdev (which BTW I do) and that was taken away I would be very upset!!!! The only we use the fbdev interface is because it is easy to port our software from one box to another and second it does mode switching for us. We don't need to write the mode switching for each box. You take that away and the reality is companies will have no real reason to use the fbdev api anymore. We will just come up with our own thing. Do you really want that to happen?

3) The BIGGEST issue is the license issue. Sorry but GPL and even LPGL doesn't fly at most companies. Most likely your library will be one of these license. Most comapnies like to use there own license. Using the fbdev api doesn't require dealing with a license but using a userland library does. This is one of the major reasons for the above libraries.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I agree. Mode switching is a core function for a low-level graphics layer.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I'm trying to get the Mobility M1 atyfb in 2.4.26 to work on Dell Latitude CPx.

If I boot he laptop with a CRT connected and run X windows everything works. The x windows log reports its using a refresh rate code of 12

Compile atyfb without generic LCD support.

If I load atyfb the screen is almost there but lots of the text is messed up. Line spacing seems correct but the actual text is unreadable. Like a clock is off or something

If I now load the X windows driver (Still using ATI driver and not FB) the same type issues apears on the graphics. It's almost there but some pixels appear to be mssing or in the wrong spot.

The X log now is pretty much identical but says that its useing a refresh rate code of 7. XCLK and reference clocks are the same.

If I boot under the LCD and run X I get refresh rate of 12 When I load atyfb the LCD blanks out. But if I "modprobe atyfb;startx" I get the same wiggy screen as under an CRT and again a refresh code of 7.

If I enable the Generic LCD support and load atyfb the LCD now displays data but has the same problem as the CRT and againg a refresh rate code of 7 if I run X and similar issues as the CRT setup yet the wiggyness is different. Still mostly recognizeable though.

Where does atyfb calculate what it need to to set the refresh rate code and any idea why it might be doing it incorrectly on this laptop?

Its my understanding that the atyfb tree in 2.4 currently has the best M1 support and not 2.6.x. If not then can someone point me to where I can find the latest patch for 2.6

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

I have the same laptop over here, and it works perfectly with 2.4.26.

dmesg:
atyfb: using auxiliary register aperture
atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
atyfb: BIOS contains driver information table.
atyfb: colour active matrix monitor detected: Samsung LT141X4-156

        id=2, 1024x768 pixels, 262144 colours (LT mode)
        supports 60 Hz refresh rates, default 60 Hz
        LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6

atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK

.config:
CONFIG_FB_ATY=y
# CONFIG_FB_ATY_GX is not set
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
# CONFIG_FB_ATY128 is not set

boot-param:
video=atyfb:1024x768-32

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Hmmm... I had GX set. Unsetting and rebuilding did change things. the text is almost readable but its still not quite right.

I was doing it as a module rather than at boot time but changing to the driver compiled in still has the same result.

My dmesg output is identical to yours. But X still logs a differnt refresh rate code of 7. What refresh rate code is in your X windows log file?

I'm doing a make clean;make bzImage right not to be sure its not some holdover of haveing GX enabled on my original build.

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Strange, {en,dis}abling GX should matter for Mach64 GX chips only.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Could be some randomness in what I'm seeing. I haven't done it enough times repeatedly to verify it does the same thing every time.

I rebuilt from a make clean and got the same result. I enabled DEBUG in the driver now and heres the output. Can you enable debug and check against your good setup.

atyfb: using auxiliary register aperture
atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
atyfb: BIOS contains driver information table.
atyfb: colour active matrix monitor detected: Samsung LT141X4-156
ati kernel:         id=2, 1024x768 pixels, 262144 colours (LT mode)
ati kernel:         supports 60 Hz refresh rates, default 60 Hz
ati kernel:         LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
ati kernel: atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
ati kernel: BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF CLOCK_CNTL
ati kernel: 7333a001 8601200a 10c57a3b e0000c81     02402200 00570628   049e05f8   00400a00
ati kernel: PLL ac ac 40 4c 87 03 c0 d4 d4 d4 00 f9 80 1b 00 00 0e cf 40 00 50 f6 ac 03 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
ati kernel: BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
ati kernel: 7333a001 8601200a 10c57a3b e0000c81     02402200 00570628   049e05f8
ati kernel: PLL ac ac 41 ec 89 03 c0 d4 d4 d4 00 00 80 1b 00 00 0e cf 40 00 50 b6 ac 10 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
ati kernel: Console: switching to colour frame buffer device 128x48

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

This is what I get:
<6>devfs: v1.12c (20020818) Richard Gooch ([email protected]) <6>devfs: boot_options: 0x0
<6>atyfb: using auxiliary register aperture
<6>atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000. <6>atyfb: BIOS contains driver information table. <6>atyfb: colour active matrix monitor detected: Samsung LT141X4-156

<4>        id=2, 1024x768 pixels, 262144 colours (LT mode)
<6>        supports 60 Hz refresh rates, default 60 Hz
<6>        LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6

<4>atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK <4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF CLOCK_CNTL
<4>7333a001 8601200a 10c57a3b e0000c81 02402200 00570628 049e05f8 00400a00
<4>PLL ac ac 40 4c 87 03 c0 d4 d4 d4 00 f9 80 1b 00 00 0e cf 40 00 50 f6 ac 03 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00 <4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7333a001 8601200a 10c57a3b e0000c81 02402200 00570628 049e05f8
<4>PLL ac ac 41 ec 89 03 c0 d4 d4 d4 00 00 80 1b 00 00 0e cf 40 00 50 b6 ac 10 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00 <4>Console: switching to colour frame buffer device 80x25

Also XFree reports refresh rate code 7
Btw, which bios version do you have?

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Mikael Eriksson wrote:

It seems our settings are identical.

Ok so its not the refresh rate either. What else can we check?

A05

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Hmm, try to update, I have A16

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Where did you find that at. All I get when I enter my service tag of 7bpap on the website is an A14.

I'm also not sure yet how I'm going to do this. There's no windows partition and I don't have a floppy drive.

Perhaps I can do something creative with a bootable CD and a bootable floppy image.

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Seems you have an CPx H, while I have a CPx J.
But I don't know what the difference is.

That should be possible.

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

And it could also handle the blending of multiple planes (one fbdev per plane)? In some sense blending (possibly scaled) planes is similar to the relative position of screens.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Agree, fbdev is too low-level to use the lock.

That should be fbdev without fbcon.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Yes and No. We _DO_ need an arbitration mecanism between fbdev (or whoever changes the mode) and other "clients" like DRI and the DRI lock would be well suited for that too. Right now, you can very easily lockup the whole box solid by just sending a mode switch down to the fbdev while DRI is active.

And since the model we are aiming too is just that: sending mode switches at any time and have all clients adapt properly, we need a solution for that. One of the reasons is hotplug displays. The hotplug is equivalent to a mode switch in this regard and will happen whatever the card is doing.

Yes, except that I'd like to see most of the mode list processing moved to userland. But I agree that the low level driver could/should be fbdev without the accel hooks. Those are really fbcon specific accel hooks, I would even like to separate it from the fbdev completely. In that sense, fbcon would just be another "client" of the framebuffer. But in this regard too, we need some arbitration.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id�66&op=click

I'm not sure that works: keep in mind that the DRM works on other OSs than Linux, and even on Linux some people may want to use the DRM without a framebuffer device. Neither should be a problem with a minimal base driver which does nothing more than hardware resource management and arbitration.

Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Differents OSs have differents sources for DRM kernel side so that's not a problem nor will affect others OSs than linux.

I would like to see fbdev becoming the defacto standard for graphics management in linux but:

1. It must mature and be modernized a lot to be accepted as such.
2. People tend to not agree.

So I see the current DRM/FBDEV/X cooperative schema for the foreseeable future.

Yes, a minimal driver would do the work _NOW_. I just think that for the long term a solution like fbdev with asteroids is needed to standarize graphics management in linux.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Nope. Most of the code in the DRI CVS drm module is shared between OSs. Most of the shared code is hardware specific though, so if you change the interface to the hardware, either all the OSs will have to provide the new interface, or the code can no longer be shared, which would get us back to the code duplication horrors. I'd very much like to avoid that.

Why wouldn't it in the future?

Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I don't see your point, nothing prevents using the shared code, the idea is not to change the interface, just to have a single graphics layer that handle that same interface. I know it could be a pain to duplicate the fbdev into the cvs drm module, but with proper file separations there could live the fbdev's drm code.

Because we need a single and unified graphics layer for linux in the very same way like the sound and input layers exists now.

A proper graphics layer based on fbdev_sysfs + libraries like the ones Ben or Jon are working on + dri + hotplug + hal + udev + dbus
+ a good graphics servers (based on the unified layer) + toolkits = a chance for linux to compete in the future with longhorn and OSX. The graphics layer I am describing here is low-level and must contain the basics needed for a graphics server. I am working on one but i'm sure it would be useful to any Xserver like the xserver from fd.o.

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

I don't see how that can be done without changing the shared code, effectively un-sharing it. Could just be me though.

Earthling Michel D채nzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Nobody says it would be easy, opossition will be fierce!

-otto

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Right. I've been discussing that problem for a while. I think we really need some common work here. When a mode change is requested by userland, we need to take that lock, but we also need to set some flag in the DRM to invalidate all state. I'm not sure what is the best way to do that at this point though.

Ben.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Being worked on. We have fbmon.c and modedb.c

This has always been. In the old days when X crashed you lost your display. That was life. The X drivers are better but its up to X to restore the console.

Sysfs will solve this.

Create a fb_info for each display port.

Agree.

2.7.X. I have been working on that for a couple of years.

I disagree. It's also a performace issue. Even if we use software drawing routines the fbcon layer still needs to draw a image, fill a region and copy a area. We can't just dump that into fbcon easily. Plus with the software cursor we do use fb_imageblit. Also I'm beginning to realize we need to clear out the framebuffer memory. People complain about left over junk on there screen when the console takes over.

I agree.

I'm not focusing on that. We have a basic api and that's it. If you don't want to program the accel engine just use the software routines. Look at the debate about how to handle setting the resolution. Yipes it been fierce.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Indeed. Try to work for a while on an unaccelerated fbcon console and you'll notice why you want acceleration.

Hardware without a CPU-accessible frame buffer is not the reason, so far those hardware was not driven by fbcon/fbdev but by their own console drivers (e.g. Indy Newport and the never merged TI34010 GSP driver).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

By that logic we'd still be using kernel 1.0. ;) I still don't see a problem with fbcon resetting the video card to what it thinks it should be when it regains control of the framebuffer. But like everything else in the kernel, we'll prove it works first before suggesting it be included in the official release.

No, no, no! :) I want to see my boot up messages before the console takes over, especially if the kernel dies during bootup. I've already posted a fix for this a while back for just the radeon driver but it's very easy to modify the other drivers. It's just one line of code per driver and one line to fb.h .

What happens is that the vga console tries to copy screen memory to it's save buffer when it's being shut down but the fb driver has already reconfigured the memory aperature layout. A call to do_blank_screen(1) right before the mode switch will cause the vga console to save screen memory at that point. This needs to be done in the drivers. If it were done in fbcon then any prink's in the drivers would "unblank" the vga console and mess things up again.

Sorry! I seem to have a nack at starting these things.... :)

John

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Hmm, but the `rules' are to round _up_ a value if it doesn't fit, or return an error.

Rounding down violates this rule.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Applied. I wonder if this means that the neofb can go back and forth to vga text mode :-)

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Yes, _all_ of the generic drawing functions expect the pseudopalette to be always u32.

Tony

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Not sure whether your question applies to the first or the second part...

... so I'll respond to the first part: yes, truecolor means a fixed (linear) CLUT, directcolor means a changeable CLUT.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

I was asking which visual is right. His patch is correct thanks to your info below.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Just curious, but if this is the case, why isn't pseudo_palette defined as a "u32 *" (instead of "void *") in struct fb_info? If anything outside the driver itself is going to be using this, it really should be more explicit what format it's supposed to be in.

For that matter, is it really kosher to have the logo code (or other things external to the driver) setting pseudo_palette directly anyway? Shouldn't there be some sort of an interface function for this (at the very least to let the driver know it's changed, in case it needs to know that sort of thing)?

-alex

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Because there can cases when the hardware requires a 16 bit value. Here we can optimize the pseudo_palette to a smaller size. This is for the case where we have hardware acceleration.

That is totally bad. In fact the code is broken in that when I attempt to draw a 4 bpp image on 16 bpp or 32 bpp framebuffers the colors come out all wrong. This is not easy to fix. All the drivers need to be brought up to date in creating a 256 palette cmap. As I update drivers you wil see this fix. Once the drivers are done the logo hacks can go away.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

In that case the pacth will be applied.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

It fixed a color map problem I had :-)

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297