From: Alex S. <al...@fo...> - 2004-04-16 02:58:45
|
Greetings all, I recently tried using the Neomagic framebuffer driver (from kernel 2.6.5) with my laptop, and noticed it seemed to have a few ...issues. :) So over the past few days I decided to go through and fix a bunch of the problems I found, and have put together quite a few patches for submission. Is this list the right place to send patches for this driver, or is there somewhere else which would be more appropriate? -alex |
From: Geert U. <ge...@li...> - 2004-04-16 08:13:59
|
On Thu, 15 Apr 2004, Alex Stewart wrote: > I recently tried using the Neomagic framebuffer driver (from kernel 2.6.5) with > my laptop, and noticed it seemed to have a few ...issues. :) > > So over the past few days I decided to go through and fix a bunch of the > problems I found, and have put together quite a few patches for submission. Is > this list the right place to send patches for this driver, or is there > somewhere else which would be more appropriate? Yes it is. You may want to CC James Simmons <jsi...@in...> to make sure it gets his attention. 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 |
From: James S. <jsi...@in...> - 2004-04-16 20:36:22
|
Yes please. I have a newer driver as well. I like to see what fixes you have. On Fri, 16 Apr 2004, Geert Uytterhoeven wrote: > On Thu, 15 Apr 2004, Alex Stewart wrote: > > I recently tried using the Neomagic framebuffer driver (from kernel 2.6.5) with > > my laptop, and noticed it seemed to have a few ...issues. :) > > > > So over the past few days I decided to go through and fix a bunch of the > > problems I found, and have put together quite a few patches for submission. Is > > this list the right place to send patches for this driver, or is there > > somewhere else which would be more appropriate? > > Yes it is. You may want to CC James Simmons <jsi...@in...> to make > sure it gets his attention. > > 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 > > > ------------------------------------------------------- > 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 > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
From: Alex T. <st...@we...> - 2004-04-19 08:51:22
|
James Simmons <jsi...@in...> writes: > Yes please. I have a newer driver as well. I like to see what fixes you > have. > BTW, James, I tried that new driver and it fixes the oops that I have reported a while ago. However, the diff that I got from infradead.org recently did not apply cleanly to official kernels. Could you post your new neofb driver as a patch against a vanilla kernel release, please? Cheers & thanks, Alex > On Fri, 16 Apr 2004, Geert Uytterhoeven wrote: > >> On Thu, 15 Apr 2004, Alex Stewart wrote: >> > I recently tried using the Neomagic framebuffer driver (from kernel 2.6.5) with >> > my laptop, and noticed it seemed to have a few ...issues. :) >> > >> > So over the past few days I decided to go through and fix a bunch of the >> > problems I found, and have put together quite a few patches for submission. Is >> > this list the right place to send patches for this driver, or is there >> > somewhere else which would be more appropriate? |
From: James S. <jsi...@in...> - 2004-04-21 04:34:56
|
I have a new pacth avaliable at http://phoenix.infradead.org:~/neofb.diff.gz Its against the latest kernel. On Mon, 19 Apr 2004, Alex Thiel wrote: > James Simmons <jsi...@in...> writes: > > > Yes please. I have a newer driver as well. I like to see what fixes you > > have. > > > > BTW, James, I tried that new driver and it fixes the oops that I have > reported a while ago. However, the diff that I got from infradead.org > recently did not apply cleanly to official kernels. > > Could you post your new neofb driver as a patch against a vanilla > kernel release, please? > > Cheers & thanks, > > Alex > > > On Fri, 16 Apr 2004, Geert Uytterhoeven wrote: > > > >> On Thu, 15 Apr 2004, Alex Stewart wrote: > >> > I recently tried using the Neomagic framebuffer driver (from kernel 2.6.5) with > >> > my laptop, and noticed it seemed to have a few ...issues. :) > >> > > >> > So over the past few days I decided to go through and fix a bunch of the > >> > problems I found, and have put together quite a few patches for submission. Is > >> > this list the right place to send patches for this driver, or is there > >> > somewhere else which would be more appropriate? > > > > ------------------------------------------------------- > 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 > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
From: Alex T. <st...@we...> - 2004-04-21 13:41:44
|
James Simmons <jsi...@in...> writes: > I have a new pacth avaliable at > > http://phoenix.infradead.org:~/neofb.diff.gz > > Its against the latest kernel. For the record, the link is http://phoenix.infradead.org/~jsimmons/neofb.diff.gz Works well over here. I also tried the patches that Alex Stewart posted and these seem to work well, too. I suggest that the new neofb driver should go into the -mm tree soon, maybe after merging Alex' fixes. Alex > > On Mon, 19 Apr 2004, Alex Thiel wrote: > >> James Simmons <jsi...@in...> writes: >> >> > Yes please. I have a newer driver as well. I like to see what fixes you >> > have. >> > >> >> BTW, James, I tried that new driver and it fixes the oops that I have >> reported a while ago. However, the diff that I got from infradead.org >> recently did not apply cleanly to official kernels. >> >> Could you post your new neofb driver as a patch against a vanilla >> kernel release, please? >> >> Cheers & thanks, >> >> Alex >> >> > On Fri, 16 Apr 2004, Geert Uytterhoeven wrote: >> > >> >> On Thu, 15 Apr 2004, Alex Stewart wrote: >> >> > I recently tried using the Neomagic framebuffer driver (from kernel 2.6.5) with >> >> > my laptop, and noticed it seemed to have a few ...issues. :) >> >> > >> >> > So over the past few days I decided to go through and fix a bunch of the >> >> > problems I found, and have put together quite a few patches for submission. Is >> >> > this list the right place to send patches for this driver, or is there >> >> > somewhere else which would be more appropriate? >> |
From: James S. <jsi...@in...> - 2004-04-21 17:40:08
|
> > Its against the latest kernel. > > For the record, the link is http://phoenix.infradead.org/~jsimmons/neofb.diff.gz > > Works well over here. > I also tried the patches that Alex Stewart posted and these seem to > work well, too. I suggest that the new neofb driver should go into > the -mm tree soon, maybe after merging Alex' fixes. That is the pan. Unfortunely his patches don't play nice with my new driver :-( |
From: Alex S. <al...@fo...> - 2004-04-21 01:14:22
|
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 |
From: James S. <jsi...@in...> - 2004-04-21 17:47:23
|
> 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. I have the same chipset. I have the new driver posted at my website. I tried your patchs but I had no luck. > Anyway, the attached patches are as follows: > > neofb.1.copyarea.patch - Fix copyarea positioning bug Yeap. Really bad bug. I fixed it in the new driver. > 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!). I tried this patch. My boot wouldn't boot with this patch. Mind you I never got the imageblit to work right. > 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. I haven't tried this one yet. Geert is this right? > 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. This can be handled by struct fb_pixmap. It padded image scan_lines to what the hardware can handle or is optimized to. > 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. Also barfed my machine :-( I really like to get i2c support going. Perhaps we should ask neomagic for the full specs for this chipset. > neofb.6.blanking.patch - Add support for DPMS blanking 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. |
From: Alex S. <al...@fo...> - 2004-04-22 03:24:36
|
On Wed, Apr 21, 2004 at 06:47:16PM +0100, James Simmons wrote: > I have the same chipset. I have the new driver posted at my website. I > tried your patchs but I had no luck. 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? > > 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!). > > I tried this patch. My boot wouldn't boot with this patch. Mind you I > never got the imageblit to work right. 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? > > 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. > > This can be handled by struct fb_pixmap. It padded image scan_lines to > what the hardware can handle or is optimized to. 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. > > 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. > > Also barfed my machine :-( I really like to get i2c support going. Perhaps > we should ask neomagic for the full specs for this chipset. Hmm.. again, what does "barfed" mean, exactly? Did you try specifying different video modes on the command line? > > neofb.6.blanking.patch - Add support for DPMS blanking > > 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. Ah, ok.. I'll make the appropriate adjustments. -alex |
From: James S. <jsi...@in...> - 2004-04-22 20:57:12
|
> On Wed, Apr 21, 2004 at 06:47:16PM +0100, James Simmons wrote: > > I have the same chipset. I have the new driver posted at my website. I > > tried your patchs but I had no luck. > > 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? 1024x768. Its a IBM thinkpad 600X. > > > > 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!). > > > > I tried this patch. My boot wouldn't boot with this patch. Mind you I > > never got the imageblit to work right. > > 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? Patched driver. I manually applied your patches. I start in 8 bpp mode. Nothing appeared on the screen. > > This can be handled by struct fb_pixmap. It padded image scan_lines to > > what the hardware can handle or is optimized to. > > 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. Okay. Cool We can work on a solution for this problem. > > > 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. > > > > Also barfed my machine :-( I really like to get i2c support going. Perhaps > > we should ask neomagic for the full specs for this chipset. > > Hmm.. again, what does "barfed" mean, exactly? Did you try specifying > different video modes on the command line? Blank screen. > > > neofb.6.blanking.patch - Add support for DPMS blanking > > > > 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. > > Ah, ok.. I'll make the appropriate adjustmen > > -alex > |
From: Alex S. <al...@fo...> - 2004-04-23 04:03:27
Attachments:
neofb-js.1.releasebug.patch
|
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 |
From: Alex S. <al...@fo...> - 2004-04-23 06:44:10
|
> 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.. 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 |
From: James S. <jsi...@in...> - 2004-04-23 23:00:29
|
> 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. |
From: Alex S. <al...@fo...> - 2004-04-24 17:29:34
|
> Got it. I merged your patches. 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 |
From: James S. <jsi...@in...> - 2004-04-25 00:55:23
|
> 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; The reason is because fb_find_mode calls check_var for us. No reason to call it twice. The large yres_virtual being 30000 that is not needed any longer. The accel flag is set in neofb_check_var. The current test is if (var->bits_per_pixel >= 24 || !par->neo2200) var->accel_flags &= ~FB_ACCEL_TEXT; Should we drop the bpp >= 24 test? Do you observe this problem at all depths. |
From: Alex S. <al...@fo...> - 2004-04-26 18:13:10
|
>> + /* 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; > > The reason is because fb_find_mode calls check_var for us. No reason > to > call it twice. The large yres_virtual being 30000 that is not needed any > longer. The accel flag is set in neofb_check_var. The current test is > > if (var->bits_per_pixel >= 24 || !par->neo2200) > var->accel_flags &= ~FB_ACCEL_TEXT; 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. > Should we drop the bpp >= 24 test? Do you observe this problem at all > depths. 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 |
From: James S. <jsi...@in...> - 2004-04-27 00:11:41
|
> > The reason is because fb_find_mode calls check_var for us. No reason > > to > > call it twice. The large yres_virtual being 30000 that is not needed any > > longer. The accel flag is set in neofb_check_var. The current test is > > > > if (var->bits_per_pixel >= 24 || !par->neo2200) > > var->accel_flags &= ~FB_ACCEL_TEXT; > > 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. Your right. I need to reverse that logic. > 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. 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. > > Should we drop the bpp >= 24 test? Do you observe this problem at all > > depths. > > 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. The new test I purpose is if (par->neo2200 && var->bits_per_pixel != 32) var->accel_flags = FB_ACCELF_TEXT; |
From: Alex S. <al...@fo...> - 2004-04-27 01:15:52
|
> 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. 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 :) > The new test I purpose is > > if (par->neo2200 && var->bits_per_pixel != 32) > var->accel_flags = FB_ACCELF_TEXT; 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 |
From: Geert U. <ge...@li...> - 2004-04-27 08:50:09
|
On Mon, 26 Apr 2004, Alex Stewart wrote: > 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?). 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 -- 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 |
From: Benjamin H. <be...@ke...> - 2004-04-27 10:17:35
|
> 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. 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. |
From: James S. <jsi...@in...> - 2004-04-27 20:25:41
|
> > 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. > > I think we should stick to KD_TEXT/KD_GRAPHICS for who owns the engine. 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 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... 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. |
From: John Z. <gr...@un...> - 2004-04-27 22:48:55
|
James Simmons wrote: >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 can see how vgacon and fbcon would walk all over each other but how would a serial console mess things up? >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. > > > Arbitration would be best. How would it be done generally? Some mechanism that arbitrates based on mem/io ranges or something else? John |
From: Benjamin H. <be...@ke...> - 2004-04-27 23:16:43
|
On Wed, 2004-04-28 at 08:48, John Zielinski wrote: > James Simmons wrote: > > >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 can see how vgacon and fbcon would walk all over each other but how > would a serial console > mess things up? Same question... Where is the problem ? > >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. > > > > > > > Arbitration would be best. How would it be done generally? Some > mechanism that arbitrates based on mem/io ranges or something else? 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, |
From: James S. <jsi...@in...> - 2004-04-27 23:21:18
|
> > I can see how vgacon and fbcon would walk all over each other but how > > would a serial console > > mess things up? > > Same question... Where is the problem ? 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. > 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 ... Ug. This is sad :-( |