From: cga2000 <cg...@op...> - 2007-02-10 06:22:44
|
I have just installed debian etch on an old laptop that sports an ATI mach64 and a 1400x1050 display and I was wondering if the atyfb module that ships with recent 2.6 kernels supports this resolution. This works beautifully with debian sarge and a 2.4.27 after you add the correct modes (?) to modedb.c .. recompile the kernel with the correct options enabled (as explained in the framebuffer console howto) .. and boot with the magical "video=atyfb:1400x1050.." parm. I was planning on copying the modes I added to my old 2.4 modedb.c to the new one. Not sure if this is going to work and if there are any caveats. Thanks, cga |
From: Ville <sy...@sc...> - 2007-02-11 15:07:45
|
On Fri, Feb 09, 2007 at 03:22:36PM -0500, cga2000 wrote: > I have just installed debian etch on an old laptop that sports an ATI > mach64 and a 1400x1050 display and I was wondering if the atyfb module > that ships with recent 2.6 kernels supports this resolution. > > This works beautifully with debian sarge and a 2.4.27 after you add the > correct modes (?) to modedb.c .. recompile the kernel with the correct > options enabled (as explained in the framebuffer console howto) .. and > boot with the magical "video=atyfb:1400x1050.." parm. > > I was planning on copying the modes I added to my old 2.4 modedb.c to > the new one. Not sure if this is going to work and if there are any > caveats. You probably don't need to add any modes. 2.6 atyfb will by default use the panel's native resolution. I'm actually writing this mail using a HP OmniBook 6000 w/ Rage Mobility and a 1400x1050 panel ;) -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
From: cga2000 <cg...@op...> - 2007-02-13 02:39:12
|
On Sun, Feb 11, 2007 at 10:07:38AM EST, Ville Syrjälä wrote: > On Fri, Feb 09, 2007 at 03:22:36PM -0500, cga2000 wrote: > > I have just installed debian etch on an old laptop that sports an ATI > > mach64 and a 1400x1050 display and I was wondering if the atyfb module > > that ships with recent 2.6 kernels supports this resolution. > > > > This works beautifully with debian sarge and a 2.4.27 after you add the > > correct modes (?) to modedb.c .. recompile the kernel with the correct > > options enabled (as explained in the framebuffer console howto) .. and > > boot with the magical "video=atyfb:1400x1050.." parm. > > > > I was planning on copying the modes I added to my old 2.4 modedb.c to > > the new one. Not sure if this is going to work and if there are any > > caveats. > > You probably don't need to add any modes. 2.6 atyfb will by default use > the panel's native resolution. I'm actually writing this mail using a HP > OmniBook 6000 w/ Rage Mobility and a 1400x1050 panel ;) Are you talking about the linux console or "X" ..? My problem is getting the _linux console_ to work at 1400x1050. Sorry if I was unclear. Because I rebooted into that system, added a "1400x1050" mode in /etc/fb.modes that I know is ok for my card/display .. did an "fbset 1400x1050" .. and I just get my prompt back .. nothing happens. I'll try to add something to /etc/modules.conf to cause atyfb to load at boot .. see if it makes a difference. I may also have to configure udev since at some point while fiddling I got a message that said something like "/dev/fb0/ non such file or directory". Thanks, cga As to my other problem -- ie. my bouncing posts, I suspect that what is happening is that I may have used a different email when I subscribed.. and I'm not sure what I should do. Maybe try all the email addresses that I have used in the past until I find the right one .. cancel my current subscription .. and subscribe again under my current email address .. sounds like the easiest way to fix this. |
From: Ville <sy...@sc...> - 2007-02-13 09:26:57
|
On Mon, Feb 12, 2007 at 09:39:03PM -0500, cga2000 wrote: > On Sun, Feb 11, 2007 at 10:07:38AM EST, Ville Syrjälä wrote: > > On Fri, Feb 09, 2007 at 03:22:36PM -0500, cga2000 wrote: > > > I have just installed debian etch on an old laptop that sports an ATI > > > mach64 and a 1400x1050 display and I was wondering if the atyfb module > > > that ships with recent 2.6 kernels supports this resolution. > > > > > > This works beautifully with debian sarge and a 2.4.27 after you add the > > > correct modes (?) to modedb.c .. recompile the kernel with the correct > > > options enabled (as explained in the framebuffer console howto) .. and > > > boot with the magical "video=atyfb:1400x1050.." parm. > > > > > > I was planning on copying the modes I added to my old 2.4 modedb.c to > > > the new one. Not sure if this is going to work and if there are any > > > caveats. > > > > You probably don't need to add any modes. 2.6 atyfb will by default use > > the panel's native resolution. I'm actually writing this mail using a HP > > OmniBook 6000 w/ Rage Mobility and a 1400x1050 panel ;) > > Are you talking about the linux console or "X" ..? Console. I don't even use regular XOrg/XF86. > My problem is getting the _linux console_ to work at 1400x1050. > > Sorry if I was unclear. > > Because I rebooted into that system, added a "1400x1050" mode in > /etc/fb.modes that I know is ok for my card/display .. did an "fbset > 1400x1050" .. and I just get my prompt back .. nothing happens. Maybe you are using vesafb instead of atyfb. Do 'cat /proc/fb'. > I'll try to add something to /etc/modules.conf to cause atyfb to load > at boot .. see if it makes a difference. I've never tried modular atyfb, I just build it into the kernel. BTW make sure you have the framebuffer console kernel config option enabled. -- Ville Syrjälä sy...@sc... http://www.sci.fi/~syrjala/ |
From: James L. <ja...@ak...> - 2007-02-14 00:03:08
|
Why does the riva driver force the virtual resolution to be as high as possible? If I can not choose to make the visible and the virtual screen size the same, then one of my frame buffer animation techniques doesn't work. I create a bitmap memory object, the size of the screen, do my rendering there and dump the whole thing to the display over and over again. In this case, there's no reason to have a virtual area bigger than the visible screen. // drivers/video/riva/fbdev.c approximately line 1232 if (var->xres_virtual < var->xres) var->xres_virtual = var->xres; //if (var->yres_virtual <= var->yres) // var->yres_virtual = -1; if (var->yres_virtual < var->yres) var->yres_virtual = var->yres; //if (rivafb_do_maximize(info, var, nom, den) < 0) // return -EINVAL; This change in the code makes it work, but the console text cursor is still visible. I also like to make the virtual screen exactly twice the size of the visible screen and render in the off screen area and switch the offsets. This works (*sort-of*) with the rivafb driver but there is some kind of sync problem. The screen does not stay lit and provide a nice smooth animation like other cards do. It looks noisy and blacks out sporadically. http://www.akrobiz.com/ezfb http://www.akrobiz.com/laserboy James. :o) |
From: cga2000 <cg...@op...> - 2007-02-12 23:17:50
|
On Sun, Feb 11, 2007 at 10:07:38AM EST, Ville Syrjälä wrote: > On Fri, Feb 09, 2007 at 03:22:36PM -0500, cga2000 wrote: > > I have just installed debian etch on an old laptop that sports an ATI > > mach64 and a 1400x1050 display and I was wondering if the atyfb module > > that ships with recent 2.6 kernels supports this resolution. > > > > This works beautifully with debian sarge and a 2.4.27 after you add the > > correct modes (?) to modedb.c .. recompile the kernel with the correct > > options enabled (as explained in the framebuffer console howto) .. and > > boot with the magical "video=atyfb:1400x1050.." parm. > > > > I was planning on copying the modes I added to my old 2.4 modedb.c to > > the new one. Not sure if this is going to work and if there are any > > caveats. > > You probably don't need to add any modes. 2.6 atyfb will by default use > the panel's native resolution. I'm actually writing this mail using a HP > OmniBook 6000 w/ Rage Mobility and a 1400x1050 panel ;) Thanks, Ville I gave it a shot and it didn't appear to work with my mach64. But then I was having other problems on this new system so I'll give it another shot and keep you posted. Thanks, cga Note: I have been subscribed to this list for a year or so and yet my original post kinda bounced with a message to the effect that I needed the moderator's approval because I wasn't a subscriber. Thanks to the person who let me in but this is rather weird. So maybe this message will likewise be delayed? |
From: cga2000 <cg...@op...> - 2007-02-14 01:22:00
|
On Tue, Feb 13, 2007 at 04:26:48AM EST, Ville Syrjälä wrote: > On Mon, Feb 12, 2007 at 09:39:03PM -0500, cga2000 wrote: <snip> > > Are you talking about the linux console or "X" ..? > > Console. I don't even use regular XOrg/XF86. > > > My problem is getting the _linux console_ to work at 1400x1050. > > > > Sorry if I was unclear. > > > > Because I rebooted into that system, added a "1400x1050" mode in > > /etc/fb.modes that I know is ok for my card/display .. did an "fbset > > 1400x1050" .. and I just get my prompt back .. nothing happens. > > Maybe you are using vesafb instead of atyfb. Do 'cat /proc/fb'. > > > I'll try to add something to /etc/modules.conf to cause atyfb to load > > at boot .. see if it makes a difference. > > I've never tried modular atyfb, I just build it into the kernel. BTW > make sure you have the framebuffer console kernel config option enabled. That's my problem. Now I remember that you must have atyfb built into the kernel for the atyfb framebuffer to work on the linux console. I checked the atyfb option in the .config file that ships with the default debian kernel and sure 'nuff it's set to `m'. As to my fbset attempt .. It's been a while and I can't find my notes .. but I'm pretty sure it's part of vesafb and not going to do anything spectacular where atyfb is concerned. So I need a reconfigured 2.6 kernel and this should work. Thanks, cga |
From: cga2000 <cg...@op...> - 2007-02-14 06:37:34
|
On Tue, Feb 13, 2007 at 04:26:48AM EST, Ville Syrjälä wrote: Works fine now I built mach64 support into the kernel. And modedb.c indeed has three 1400x1050 modes to choose from. I'll take a closer look tomorrow but since they don't have names/identifiers in the code, I'm not sure how one is chosen over the others. Not that it matters, the difference in crispness/definition of the fonts on my display now that I'm running at the LCD's native resolution is just unbelievable. Thanks for your help. cga. |