Re: vesa mode code?
Hi. On Tue, Apr 08, 2014 at 04:20:22PM +0200, Hans wrote: Hi there, I am asking myself now for many years, if there is a relationship between the solution and the vesacode at the grub commandline. Of course, there is a table everywhere, where I can see, which resolution is at the givenm mode (i.e. vga=791 is 1024x768). But what does 791 mean? I guess it is 791h, or similar. Documentation/svga.txt (linux kernel documentation, any version should do) should give you some insight into this matter. Short answer is no, 791 is not 791h, it's 317h. And 317h is defined by VESA 2.0 as 1024x768x16. Is it possible (and if yes, how), to compute the code from the wanted solution? For example, if I want to have 1440x900, can I compute the vga=whatever code? Or must I always look into a table? Sure, there's a way. Install 'hwinfo', invoke hwinfo --framebuffer from the console as root. vga= value you need should be 866 or 867. Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140408144958.GA22048@x101h
Re: vesa mode code?
On 09/04/14 00:20, Hans wrote: Hi there, I am asking myself now for many years, if there is a relationship between the solution and the vesacode at the grub commandline. Do you mean if you type c at the GRUB prompt and then vbeinfo? Those are the frame buffer modes your screen can handle. hwinfo --framebuffer will give you the same info. Of course, there is a table everywhere, where I can see, which resolution is at the givenm mode (i.e. vga=791 is 1024x768). But what does 791 mean? I guess it is 791h, or similar. The video mode number of the Linux kernel is the VESA mode number plus 0x200 Is it possible (and if yes, how), to compute the code from the wanted solution? For example, if I want to have 1440x900, can I compute the vga=whatever code? Or must I always look into a table? I googled, but found only tables, but no satisfying explanations. Some explanation:- https://www.kernel.org/doc/Documentation/svga.txt https://www.kernel.org/doc/Documentation/fb/vesafb.txt Would be nice, if someone could tell me more. Best Hans Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53440eb7.6070...@gmail.com
Re: vesa mode code?
The video mode number of the Linux kernel is the VESA mode number plus 0x200 No no, what I mean is the following: Guess, I want to have a special resolution at boot, for example 800x600x32. Now I need the vga=whatever. To get it, I can look into a list and see, yes, it is vga=789. This is simple. But when there is no list available, how can I compute from 800x600x32 to the needed result vga=789? Is there a way if any, or was (in my example) the data 789 just a fixed set/number? Hope, I made my question clearer. Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1735761.MSkaBTYJfk@protheus2
Re: vesa mode code?
On Ma, 08 apr 14, 16:20:22, Hans wrote: Is it possible (and if yes, how), to compute the code from the wanted solution? For example, if I want to have 1440x900, can I compute the vga=whatever code? Or must I always look into a table? Not what you're asking for, but maybe what you need: with recent enough grub and kernel (wheezy and probably even earlier) you only need to set GRUB_GFXPAYLOAD_LINUX=1440x900 in /etc/default/grub, or set it to 'keep' and change GRUB_GFXMODE as needed. Whether your card actually supports the mode is a completely different question, but has already been answered by others. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: vesa mode code?
Hi Andrei, GRUB_GFXPAYLOAD_LINUX=1440x900 I know this variable. It is from grub2, I know. Besides I am still using grub- legacy, my problem is not to find the correct vga= for my resolution. I know this one. No, I could not find an answer, if the number from the vga= can be computed out of the wanted resolution. So, for example, 800x600x32 = 789h(ex) or whatever. Kind regards, Andrei Maybe my English is too bad, so my question is misunderstood. Best Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5777306.ypnjbBHf8O@protheus2
Re: vesa mode code?
On Ma, 08 apr 14, 17:48:17, Hans wrote: No, I could not find an answer, if the number from the vga= can be computed out of the wanted resolution. So, for example, 800x600x32 = 789h(ex) or whatever. ... Maybe my English is too bad, so my question is misunderstood. You question was well understood and already answered by Reco and Scott, but I thought it was a case of XY problem ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: vesa mode code?
On 09/04/14 01:33, Andrei POPESCU wrote: On Ma, 08 apr 14, 16:20:22, Hans wrote: Is it possible (and if yes, how), to compute the code from the wanted solution? For example, if I want to have 1440x900, can I compute the vga=whatever code? Or must I always look into a table? See:- https://wiki.archlinux.org/index.php/GRUB_Legacy#Framebuffer_resolution vbetool will probably give you the same info. More detailed information on calculating mode numbers:- http://wiki.antlinux.com/pmwiki.php?n=HowTos.VgaModes Not what you're asking for, but maybe what you need: with recent enough grub and kernel (wheezy and probably even earlier) you only need to set GRUB_GFXPAYLOAD_LINUX=1440x900 in /etc/default/grub, or set it to 'keep' and change GRUB_GFXMODE as needed. Whether your card actually supports the mode is a completely different question, but has already been answered by others. This is because the graphic card manufacturers are free to choose any number they wish, as this is not part of the VBE 3 standard. This is why these codes change from one card to the other (possibly even for the same manufacturer). Kind regards, Andrei With the benefit of hindsight, if the OP had mentioned right at the start he was using GRUB legacy (or LILO) we'd have supplied more useful information. Kind regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534421c0.7010...@gmail.com
[SOLVED] Re: vesa mode code?
Am Mittwoch, 9. April 2014, 02:20:16 schrieb Scott Ferguson: On 09/04/14 01:33, Andrei POPESCU wrote: On Ma, 08 apr 14, 16:20:22, Hans wrote: Is it possible (and if yes, how), to compute the code from the wanted solution? For example, if I want to have 1440x900, can I compute the vga=whatever code? Or must I always look into a table? See:- https://wiki.archlinux.org/index.php/GRUB_Legacy#Framebuffer_resolution vbetool will probably give you the same info. More detailed information on calculating mode numbers:- http://wiki.antlinux.com/pmwiki.php?n=HowTos.VgaModes Hi Scott, Andrei and all the others, who helped me. The link, Scott sent was exactly the thing I searched for. Now I know, why there are different expressions (like hex or decimal) and why it is working the way, it does. I looked for it a long time, and at last I dared to ask. As I am using linux now for such a long time, this thing was always a question in my mind, and I did not want to be a morone, to ask for it. However, there is always something to learn. Thank you very much for your help. Problem solved! Great! Cheers Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1644336.jDutdXJP5D@protheus2
Re: vesa 1280x800
On Saturday 12 January 2008 00:59, Douglas A. Tutty wrote: On Fri, Jan 11, 2008 at 10:21:56AM +0100, Kum Gabor wrote: Can somebody help me how to set up 1280x800 on Etch with vesa driver? For me only 1280x720 is working. (video is SiS672) That may not be possible for the vesa driver (see the vesa(4) man page) as it only accesses the basic vesa-compliant hardware. Why not use the sis (SiS) driver? see man sis(4) Doug. Because It is not working with my SiS672 chip. I have a driver, but it is not working on Etch. So I must decide Etch or 1280x800. :( -- Kum Gabor www.kumgabor.hu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa 1280x800
On Sat, Jan 12, 2008 at 10:50:01AM +0100, Kum Gabor wrote: On Saturday 12 January 2008 00:59, Douglas A. Tutty wrote: On Fri, Jan 11, 2008 at 10:21:56AM +0100, Kum Gabor wrote: Can somebody help me how to set up 1280x800 on Etch with vesa driver? For me only 1280x720 is working. (video is SiS672) That may not be possible for the vesa driver (see the vesa(4) man page) as it only accesses the basic vesa-compliant hardware. Why not use the sis (SiS) driver? see man sis(4) Doug. Because It is not working with my SiS672 chip. I have a driver, but it is not working on Etch. So I must decide Etch or 1280x800. :( But I haven't seen any thread of you asking for SiS help. Perhaps start a new thread with SiS in the title and give details and what errors you get to mean that it doesn't work. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa 1280x800
On Saturday 12 January 2008 16:11, Douglas A. Tutty wrote: On Sat, Jan 12, 2008 at 10:50:01AM +0100, Kum Gabor wrote: On Saturday 12 January 2008 00:59, Douglas A. Tutty wrote: On Fri, Jan 11, 2008 at 10:21:56AM +0100, Kum Gabor wrote: Can somebody help me how to set up 1280x800 on Etch with vesa driver? For me only 1280x720 is working. (video is SiS672) That may not be possible for the vesa driver (see the vesa(4) man page) as it only accesses the basic vesa-compliant hardware. Why not use the sis (SiS) driver? see man sis(4) Doug. Because It is not working with my SiS672 chip. I have a driver, but it is not working on Etch. So I must decide Etch or 1280x800. :( But I haven't seen any thread of you asking for SiS help. Perhaps start a new thread with SiS in the title and give details and what errors you get to mean that it doesn't work. Doug. Glibc? (SiS671/ SiS672 driver on Etch) - this thread was about it. -- Kum Gabor www.kumgabor.hu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa 1280x800
On Jan 12, 2008 2:39 PM, Kum Gabor [EMAIL PROTECTED] wrote: On Saturday 12 January 2008 16:11, Douglas A. Tutty wrote: On Sat, Jan 12, 2008 at 10:50:01AM +0100, Kum Gabor wrote: On Saturday 12 January 2008 00:59, Douglas A. Tutty wrote: On Fri, Jan 11, 2008 at 10:21:56AM +0100, Kum Gabor wrote: Can somebody help me how to set up 1280x800 on Etch with vesa driver? For me only 1280x720 is working. (video is SiS672) That may not be possible for the vesa driver (see the vesa(4) man page) as it only accesses the basic vesa-compliant hardware. Why not use the sis (SiS) driver? see man sis(4) Doug. Because It is not working with my SiS672 chip. I have a driver, but it is not working on Etch. So I must decide Etch or 1280x800. :( But I haven't seen any thread of you asking for SiS help. Perhaps start a new thread with SiS in the title and give details and what errors you get to mean that it doesn't work. Doug. Glibc? (SiS671/ SiS672 driver on Etch) - this thread was about it. This thread was apparently about the vesa driver, not the SiS driver. Glibc is the GNU C library (the fundamental system library), not the SiS driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa 1280x800
On Fri, Jan 11, 2008 at 10:21:56AM +0100, Kum Gabor wrote: Can somebody help me how to set up 1280x800 on Etch with vesa driver? For me only 1280x720 is working. (video is SiS672) That may not be possible for the vesa driver (see the vesa(4) man page) as it only accesses the basic vesa-compliant hardware. Why not use the sis (SiS) driver? see man sis(4) Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 07:44:14PM -0500, Owen Heisler wrote: Anyway, I tried some other video= lines and nothing makes any difference. I tried vesafb, rivafb, and nvidiafb for the driver and both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all combinations for rivafb and nvidiafb, not vesafb:1024x768 I think). I don't know if it is relevant, but once the system is booted, I can load a nvidiafb module, but not either of vesafb and rivafb. That's normal. vesafb is compiled in (not a module) and rivafb is not compiled at all. Like I said, this isn't really a problem; if I just need to make a custom kernel, I'll drop it for now and maybe later... sometime... Here is what I would try: 1. A simple vga= to the kernel (vga=791 should give 1024x764-16bpp). If this works you only need to find the correct parameter to get the right resolution (though it is already better than 640x480). 2. Find out what the correct driver for your video card is. AFAIR rivafb is only for *very* old cards. The newer ones should work with the nvidiafb. 3. Put nvidiafb in your initrd and boot with the correct video=nvidiafb:... option. You must google for the exact parameters to pass as they might be different from other drivers. 1. with the correct parameter might be enough, but if it doesn't work or doesn't give the desired resolution you might experiment with 2. and 3. None of them involves kernel compilation. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, 2007-05-22 at 09:33 +0300, Andrei Popescu wrote: On Mon, May 21, 2007 at 07:44:14PM -0500, Owen Heisler wrote: Anyway, I tried some other video= lines and nothing makes any difference. I tried vesafb, rivafb, and nvidiafb for the driver and both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all combinations for rivafb and nvidiafb, not vesafb:1024x768 I think). I don't know if it is relevant, but once the system is booted, I can load a nvidiafb module, but not either of vesafb and rivafb. That's normal. vesafb is compiled in (not a module) and rivafb is not compiled at all. Okay Like I said, this isn't really a problem; if I just need to make a custom kernel, I'll drop it for now and maybe later... sometime... Here is what I would try: 1. A simple vga= to the kernel (vga=791 should give 1024x764-16bpp). If this works you only need to find the correct parameter to get the right resolution (though it is already better than 640x480). There doesn't seem to be a correct vga= parameter for 1280x960. 2. Find out what the correct driver for your video card is. AFAIR rivafb is only for *very* old cards. The newer ones should work with the nvidiafb. Mine is not old, so nvidiafb should be correct. 3. Put nvidiafb in your initrd and boot with the correct video=nvidiafb:... option. You must google for the exact parameters to pass as they might be different from other drivers. I've tried video=nvidiafb:1280x960 and I seem to just get the default resolution. So I need a full framebuffer mode line, I guess. In order to figure out what I need to use, I need this information (as provided by XFree86): Modeline 1280x960 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old) 1. with the correct parameter might be enough, but if it doesn't work or doesn't give the desired resolution you might experiment with 2. and 3. None of them involves kernel compilation. 3 it is. Thanks signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, May 22, 2007 at 07:24:40AM -0500, Owen Heisler wrote: There doesn't seem to be a correct vga= parameter for 1280x960. I was suggesting 791 as it is still better then the default and you can see something happening (I just hate it when I mess with options and I see no change :)) I've tried video=nvidiafb:1280x960 and I seem to just get the default resolution. So I need a full framebuffer mode line, I guess. In order to figure out what I need to use, I need this information (as provided by XFree86): Modeline 1280x960 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old) Did you include the nvidiafb module in your initrd? I run yaird and don't know how to do this for initramfs-tools. If yes then you could (again) try a resolution like 1024x768, just to see your changes are going to the right place and then see how to get to the right resolution. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, 2007-05-22 at 18:56 +0300, Andrei Popescu wrote: On Tue, May 22, 2007 at 07:24:40AM -0500, Owen Heisler wrote: There doesn't seem to be a correct vga= parameter for 1280x960. I was suggesting 791 as it is still better then the default and you can see something happening (I just hate it when I mess with options and I see no change :)) Oh, I've been using vga=791 for a while now. Just wondering if I can get 1280x960 instead! :) And yes, I agree: when I change something I'd really like to see /something/, whether a change for the better, for the worse, or even just some cryptic (or not) error. I've tried video=nvidiafb:1280x960 and I seem to just get the default resolution. So I need a full framebuffer mode line, I guess. In order to figure out what I need to use, I need this information (as provided by XFree86): Modeline 1280x960 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL see http://www.linux.com/howtos/Framebuffer-HOWTO-18.shtml (old) Did you include the nvidiafb module in your initrd? I run yaird and don't know how to do this for initramfs-tools. If yes then you could (again) try a resolution like 1024x768, just to see your changes are going to the right place and then see how to get to the right resolution. I've never done anything with initrd stuff before, but I see that /etc/initramfs-tools/initramfs.conf contains: # MODULES: [ most | netboot | dep | list ] # most - Add all framebuffer, acpi, filesystem, and harddrive drivers. MODULES=most So I assume that nvidiafb is in there. But when I look inside /boot/initrd* at lib/modules/*/kernel/drivers/video, I see only: vga16fb.ko and vgastate.ko So I add nvidiafb to /etc/initramfs-tools/modules, run update-initramfs -u (this is fun) and now nvidia is also listed. Now I reboot and try video=nvidiafb:1280x960 and video=nvidiafb:1024x768 and get something slightly worse than the default with both. Do I need more after video=? signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Tue, May 22, 2007 at 06:28:50PM -0500, Owen Heisler wrote: So I add nvidiafb to /etc/initramfs-tools/modules, run update-initramfs -u (this is fun) and now nvidia is also listed. Now I reboot and try video=nvidiafb:1280x960 and video=nvidiafb:1024x768 and get something slightly worse than the default with both. Do I need more after video=? I don't know. Try (as root) 'modinfo nvidiafb' and google. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 02:44:29AM EDT, Andrei Popescu wrote: On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. How is the initrd going to help if the module does not exist in the first place? What I was saying is that support for his card may have been included in whatever kernel he's using .. either built-in or as a module. The other aspect is that initrd or not .. I have never managed to get the frame buffer console to start when using atyfb instead of the generic vesa when compiling it as a module. But that's a separate issue. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 08:18:37AM -0400, cga2000 wrote: On Mon, May 21, 2007 at 02:44:29AM EDT, Andrei Popescu wrote: On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. How is the initrd going to help if the module does not exist in the first place? You're right, the rivafb module is not compiled, but vesafb is compiled in and it should work with the correct vga=... There is a nvidiafb module, maybe the OP can try that? What I was saying is that support for his card may have been included in whatever kernel he's using .. either built-in or as a module. Sorry, I thought you were telling him he needs to recompile the kernel. I missed the may. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, May 21, 2007 at 12:35:57PM EDT, Andrei Popescu wrote: On Mon, May 21, 2007 at 08:18:37AM -0400, cga2000 wrote: On Mon, May 21, 2007 at 02:44:29AM EDT, Andrei Popescu wrote: On Sun, May 20, 2007 at 11:06:39PM -0400, cga2000 wrote: I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Not necessarily. It should work if you inlcude the module in your initrd. How is the initrd going to help if the module does not exist in the first place? You're right, the rivafb module is not compiled, but vesafb is compiled in and it should work with the correct vga=... This actually should work if both vesafb and the native driver (in this instance rivafb) are compiled in. Would allow you to switch on the fly (in grub) by specifying: kernel ... video=vesafb:1024x768 kernel ... video=rivafb:1024x768 .. so you can use either with the same kernel. The above would be clean and simple .. but I'm not sure that's the way things work (haven't tested it) .. It would help if the OP could explain _how_ it doesn't work. _Owen_, What do you get .. a kernel oops .. a black screen of death .. a vga console with oversized fonts ..? With little detail about what's happening .. I would suggest building a kernel with support for you hardware built in .. rather than provided via a module. That's how I eventually got this to work with a 2.4.27 kernel atyfb/mach64. There is a nvidiafb module, maybe the OP can try that? What I was saying is that support for his card may have been included in whatever kernel he's using .. either built-in or as a module. Sorry, I thought you were telling him he needs to recompile the kernel. I missed the may. I suspect that debian kernels are compiled w/o native driver support because the sum total of all the specific drivers ends up support only a subset of the hundreds or video cards chipsets available .. and since once they're present they would appear to preempt vesa support .. So, I would say I am reasonably confident he will end up making his own custom kernel if he wants to use the native driver for his video card. If you can't explain it simply, you don't understand it well enough. (Albert Einstein) So that's where I ran into this little jewel, then. Actually grepped my fortune database for it the other day to check on the exact wording. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Mon, 2007-05-21 at 19:27 -0400, cga2000 wrote: _Owen_, What do you get .. a kernel oops .. a black screen of death .. a vga console with oversized fonts ..? With any video= parameter, I get the default resolution (640x480/80x25, I suppose), just like there was no vga= or video= parameter appended to the kernel boot line. With little detail about what's happening .. I would suggest building a kernel with support for you hardware built in .. rather than provided via a module. That's how I eventually got this to work with a 2.4.27 kernel atyfb/mach64. ... I suspect that debian kernels are compiled w/o native driver support because the sum total of all the specific drivers ends up support only a subset of the hundreds or video cards chipsets available .. and since once they're present they would appear to preempt vesa support .. So, I would say I am reasonably confident he will end up making his own custom kernel if he wants to use the native driver for his video card. Yeah, last time I compiled a custom kernel was back when I first started using Linux, with Fedora Core... I thought I had to for some hardware problem or something... (New to Linux, and impressed that everything just worked even when using the latest kernel, and compiled by me who knew nothing about it) I was glad to discover later that it wasn't really necessary. And now my policy is to use stock kernels in Debian unless I absolutely have to use a custom kernel, because it simplifies things so much. (Wait, maybe it's a lot easier on Debian, using deb sources... perhaps I'll investigate sometime.) :) And this isn't really a problem: it just bugs me that I have to wait for my CRT monitor to switch resolutions when switching between X and other consoles. Anyway, I tried some other video= lines and nothing makes any difference. I tried vesafb, rivafb, and nvidiafb for the driver and both 1024x768 (vga=791 works fine) and 1280x960 for the resolution (all combinations for rivafb and nvidiafb, not vesafb:1024x768 I think). I don't know if it is relevant, but once the system is booted, I can load a nvidiafb module, but not either of vesafb and rivafb. Why am I not getting any errors? I can't find anything in /var/log, searching for video or nvidia. Hopefully this is irrelevant: the root fs is encrypted on top of RAID5. Like I said, this isn't really a problem; if I just need to make a custom kernel, I'll drop it for now and maybe later... sometime... Thanks signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, 2007-05-20 at 01:10 -0400, cga2000 wrote: On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? Oh .. maybe, $ modeline2fb Same fbset package as the other stuff previously mentioned. Mind if I add snippets of you two posts to Owen to that Vesa Mode Page? -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, May 20, 2007 at 12:01:18PM EDT, Greg Folkert wrote: [..} Mind if I add snippets of you two posts to Owen to that Vesa Mode Page? Not in principle naturally. Just that I'd be a little concerned about the contents of my posts possibly misleading others .. A clear case of I don't understand it well enough to explain it .. to paraphrase A. Einstein, I think. I wish I had more solid knowledge of these aspects. Obviously, since I have not one but two systems that work flawlessly with the atyfb driver and a mach64, albeit somewhat differently (see below) .. I am in a good position to provide you with any files on my system that you think might be of interest. In any event, I should probably mention one other thing that I have read/heard on the subject, which is that if both vesa and the native driver are enabled in your kernel config, the native driver wins. This may be useful since grub lets you easily change your boot options on the fly .. eg. to recover from a messed up situation. Also, I am currently setting up an etch system on the same laptop and after my posting late last night, I noticed that my grub menu entries for the etch system do not specify anything regarding the fb console at all..! No video=atyfb or specifying the dimensions of my display in pixels. And yet, the laptop boots by default into its native 1400x1050 mode. No artifacts .. a perfect display as on a bran new high-end hardware terminal. This, btw is with the more recent 2.6.20 kernel (I typically run sarge with a 2.4.27 custom kernel). I also vaguely remember that, much to my delight, the 1400x1050 mode was already defined in the source file that contains all the modelines. But I had to compile custom kernels over and over for a number of other reasons .. so I'm not sure any more whether the kernel config I started off with had ati support enabled by default or if I had to enable it myself. The former, I think. Rather revealing of the maturity of the atyfb driver..! I requested from the ubuntu folks that they add this mode to their live system cd at least .. and possibly the installer .. to no avail .. that was about two years ago. Do you have access to a system where you could run some tests with possibly another video card than my old mach64..? I was thinking if you had some hands-on experience of this not so well documented area .. it might help clarify the process .. correct possible errors and omissions on my part .. make sure there is no miscommunication .. as well as .. if you are successful .. being able to add at least one video card to your database of video cards that we know for a fact are fully supported by a native driver. I should also add that from the user angle the results in my case were well worth the effort since the only (major where I am concerned) visual difference between my linux console and a full-screen xterm on my etch system is the fact that the linux console is limited to 16 colors rather than xterm's 256. Unfortunately, although I have fiddled with a couple of programs that let you dump an fb console to a file I have not been successful and so I do not have screenshots to prove it. Sorry about the vagueness/verbosity of the above but that's just about all I have been able to figure out so far. If I understood the fb console a bit better, I would be a lot more terse and I might consider updating that obsolete Framebuffer Console HOWTO. Regrettably, I have never had the time to work and play with the code of at least my own video card's driver. Oh, if you do decide to add something to your web page, please let me know and I'll be glad to take a look. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, 2007-05-20 at 17:25 -0400, cga2000 wrote: On Sun, May 20, 2007 at 12:01:18PM EDT, Greg Folkert wrote: Mind if I add snippets of you two posts to Owen to that Vesa Mode Page? Not in principle naturally. [snip] Oh, if you do decide to add something to your web page, please let me know and I'll be glad to take a look. I'll just pass then. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, 2007-05-20 at 01:10 -0400, cga2000 wrote: On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? Oh .. maybe, $ modeline2fb Same fbset package as the other stuff previously mentioned. A list of the available video drivers here (?): http://linux-fbdev.sourceforge.net/driverlist.php I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sun, May 20, 2007 at 07:25:41PM EDT, Owen Heisler wrote: [..] A list of the available video drivers here (?): http://linux-fbdev.sourceforge.net/driverlist.php I tried: video=rivafb:1280x960 video=vesafb:1280x960 but neither worked. You do realize that you may need to compile a custom kernel to enable support for a given video card..? Something else that I didn't mention. I was never able get the framebuffer console to initialize correctly when support for my card was specified via a M module. This may no longer be the case .. maybe I didn't do it right .. but I recommend you specify an * in your kernel's config .. meaning built-in support. I have a feeling the above page is not current. It says kernel 2.4 on each and every line and that's hardly bleeding edge. Obviously, developers are not all that interested in 2-3 year old kernels. On the other hand, after all the time I spent looking for solutions to my problem, I'd say some of the names on that page look familiar and I'm sure that even if one person in particular doesn't or no longer supports the particular driver you're interested in .. they would gladly direct you to the current maintainer should you decide to email them directly. They don't have such a large user base so someone genuinely interested who might dig up some real problem or other is usually of interest to them. But I would make sure to identify the correct party before emailing them. The output of $ lspci -vv and a quick peek at a recent kernel's ../drivers/ video subtree .. might help (?) Be aware that the video card is sometimes not the end of the story. This was the case with my mach64 where some versions were fully supported and others weren't .. because a different version of the chip that the card uses (or a different chip altogether) can make all the difference. Good luck with it and you're welcome to get back to me on/off-list if you think I may be able to help. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. Okay hwinfo --vbe doesn't mention 1280x960 here either. signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, 2007-05-19 at 17:09 -0500, Owen Heisler wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. Okay hwinfo --vbe doesn't mention 1280x960 here either. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? And what do I use for the framebuffer device (video=)? Thanks signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, 2007-05-19 at 18:33 -0500, Owen Heisler wrote: video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? And what do I use for the framebuffer device (video=)? I don't know. Exactly why I said they have really been updated since 2000 or 2001. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? And what do I use for the framebuffer device (video=)? I missed the earlier posts on this thread so this is a bit of a shot in the dark. Please ignore if this is .. er .. off topic :-) I believe video= is card-specific and you need to specify the name of the kernel video driver that supports your card .. if there is one, that is. I have an antique laptop with an ATI Mach64 card which is fully supported by the atyfb driver. So I specify this in my grub menu file: kernel /boot/vmlinuz-2.4.27.041213.2 root=/dev/hda11 ro video=atyfb:1400x1050 In other words, I do not use the generic vga/vesa driver .. the one that has the vga=791 .. etc. syntax .. but rather one that's specific to my hardware. The reason I use it rather than the generic is that among other things it lets me run a 1400x1050 linux console which happens to be the native mode of my laptop's panel, taking care of the blurred fonts I was getting with other modes available with the generic driver such as 1024x768 .. Makes a huge difference. It also gives me twice the real-estate ~1.4M vs. ~0.7M pixels or so .. while maintaining the correct 4:3 ratio as opposed to the wide-screen mode of 1280x1024 that I used for a while with the generic driver. In order to get this to work I had to do a bit of kernel configuration to enable support for my card .. add the 1400x1050 mode to some file or other in the ../drivers/ sub-directory of the kernel source tree .. I think this file is common to all the different drivers .. and naturally build a custom kernel. Depending on your card .. which kernel you are using .. who built it .. whether he enabled the driver that you need .. the mode you plan to use .. all the above may not even be necessary. And then again your particular card may not be supported .. in which case you're out of luck and will have to stick with the generic driver until someone adds support for your particular hardware. Unfortunately, I don't know of a site that has the list of currently supported cards and which particular module supports each of them. In any case, the semi-obsolete framebuffer console HOWTO is worth a read. Other places to look for additional info: $ man fbset $ man 5 fb.modes You probably need to do an apt-get install fbset of similar to have access to these documents on your machine. HTH Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Sat, May 19, 2007 at 07:33:51PM EDT, Owen Heisler wrote: On Sat, 2007-05-19 at 19:10 -0400, Greg Folkert wrote: On Fri, 2007-05-18 at 00:10 -0400, Greg Folkert wrote: On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. FYI, I've updated the page and now lists a few things to get other modes. Though the framebuffer howtos have not really been updated since 2000 or 2001. video=:xres:,yres:,depth:,left:,right:,hslen:,upper:,lower:,vslen: It looks like I need something like this: Modeline 1280x1024 DCF HR SH1 SH2 HFL VR SV1 SV2 VFL Is there some way to get that from xorg? Oh .. maybe, $ modeline2fb Same fbset package as the other stuff previously mentioned. Thanks, cga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa display codes (Etch Xorg memory leak?)
On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? signature.asc Description: This is a digitally signed message part
Re: vesa display codes (Etch Xorg memory leak?)
On Thu, 2007-05-17 at 18:34 -0500, Owen Heisler wrote: On Thu, 2007-05-17 at 16:02 -0400, Greg Folkert wrote: http://www.gregfolkert.net/info/vesa-display-codes.html Very helpful! Although no 1280x960 (grr) unfortunately. Is there any way to get that? vbetool is supposed to do it. Or hwinfo --vbe But they aren't exactly 100%, as I haven't been able to get the info out of the hardware yet. -- greg, [EMAIL PROTECTED] PGP key: 1024D/B524687C 2003-08-05 Fingerprint: E1D3 E3D7 5850 957E FED0 2B3A ED66 6971 B524 687C Alternate Fingerprint: 09F9 1102 9D74 E35B D841 56C5 6356 88C0 signature.asc Description: This is a digitally signed message part
Re: vesa mode for MPlayer compile problem
On Thu, Dec 01, 2005 at 10:36:04PM +0100, Dirk wrote: which package containes vbe.h ? MPlayer needs it for the vesa mode output... apt-get install apt-file apt-file update apt-file search vbe.h signature.asc Description: Digital signature
Re: vesa mode for MPlayer compile problem
Almut Behrens wrote: On Thu, Dec 01, 2005 at 10:36:04PM +0100, Dirk wrote: which package containes vbe.h ? MPlayer needs it for the vesa mode output... Just grepped in the mplayer sources for a reference of vbe.h, but couldn't find anything -- so, not sure what exactly you need... Normally, for the true VESA mode (running under LRMI (Linux real-mode interface)) there's a library vbelib that comes with the mplayer sources. The respective header file is osdep/vbelib.h. Maybe that's what you need? Which mplayer source version do you have? I tried the cvs versions of the last 1 1/2 months... Which of your source files is referencing vbe.h? What errors do you get, i.e. which symbols is the compiler complaining about? -- that might help to figure out which vbe.h/driver/library you need... (there's most likely more than one in this world... :) i don't get as far as compilation... configure already says that vesa is disabled.. because it checks for vbe.h As a first approximation, I'd just try editing the respective file to include something like osdep/vbelib.h instead (make sure the relative path is correct, so it is found...). That would seem to make more sense to me (maybe it's just a typo in the sources you have). i'll give it a try.. Thanks, Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa mode for MPlayer compile problem
On Thu, Dec 01, 2005 at 10:36:04PM +0100, Dirk wrote: which package containes vbe.h ? MPlayer needs it for the vesa mode output... Just grepped in the mplayer sources for a reference of vbe.h, but couldn't find anything -- so, not sure what exactly you need... Normally, for the true VESA mode (running under LRMI (Linux real-mode interface)) there's a library vbelib that comes with the mplayer sources. The respective header file is osdep/vbelib.h. Maybe that's what you need? Which mplayer source version do you have? Which of your source files is referencing vbe.h? What errors do you get, i.e. which symbols is the compiler complaining about? -- that might help to figure out which vbe.h/driver/library you need... (there's most likely more than one in this world... :) As a first approximation, I'd just try editing the respective file to include something like osdep/vbelib.h instead (make sure the relative path is correct, so it is found...). That would seem to make more sense to me (maybe it's just a typo in the sources you have). HTH, Almut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: vesa-framebuffer is not working
On Wed, May 25, 2005 at 08:46:27PM +0530, Joydeep Bakshi wrote: *dmesg|grep vesa* shows --- vesafb: probe of vesafb0 failed with error -6 ^ I'm not really knowledgable in this area, but I saw this message on my box as well. I didn't notice any strange behaviour, but I don't know what I should be looking for. I did some googling and didn't find anything worth panicking about. These message might shed some light: http://lists.debian.org/debian-boot/2004/07/msg00428.html http://lists.debian.org/debian-boot/2004/07/msg00435.html All of problem looks kernel(or modprobe) loads vesafb in spite of it reports an error. So you may want to check if vesafb is loaded correctly after all. Try the following as root: # lsmod | grep vesafb In my case I see as output: vesafb 6688 0 cfbcopyarea 3840 1 vesafb cfbimgblt 3072 1 vesafb cfbfillrect 3712 1 vesafb So at least something is loaded. But I notice that this is vesafb while the error seems to be about vesafb0. -- Maurits van Rees | http://maurits.vanrees.org/ [Dutch/Nederlands] Public GnuPG key: keyserver.net ID 0x1735C5C2 Let your advance worrying become advance thinking and planning. - Winston Churchill signature.asc Description: Digital signature
Re: vesa driver crashes
On Mon, Feb 10, 2003 at 02:37:06PM +0800, Joel M. Pareja wrote: I am running woody(initial release) on a P4 machine. The version of X does not support the ProSavageDDR video card built-in to my P4MFM motherboard. When choosing the vesa driver, after some flickers it works OK. The problem arises, when I switch to the virtual console(e.g. tty1). The system just freezes. No activity at all. That doesn't sound good at all. It might just be a flaw with the vesa driver or the card though...Have you googled for similar symptoms? $ XFree86 -version XFree86 Version 4.1.0.1 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 21 December 2001 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Build Operating System: Linux 2.4.17 i686 [ELF] It's possible that X 4.2 might work better (or so I hear); a driver specific to your card would be even better though. If you decide to try X4.2, you can get debs for woody from http://people.debian.org/~blade/woody/. -- Rob Weir [EMAIL PROTECTED] http://ertius.org/ msg30080/pgp0.pgp Description: PGP signature
Re: VESA Framebuffer
On 09 Feb 2003 21:36:36 -0300 Héctor Luis Gimbatti [EMAIL PROTECTED] wrote: On Sat, 2003-02-08 at 09:34, none wrote: On Tue, 31 Dec 2002 13:07:49 -0300 root [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Buenas. He leído y comprobado que el VESA FB es mucho mas lento que un famebuffer nativo de mi placa, pero, ya que la misma no me lo soporta, he usado el vesa FB. Ahora, nadie tiene tips sobre como acelerar el framebuffer? mi configuracion actual del mismo es: mode 1024x768-76 # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 16 timings 12714 128 32 16 4 128 4 rgba 5/11,6/5,5/0,0/0 endmode Frame buffer device information: Name: VESA VGA Address : 0xdc00 Size: 4194304 Type: PACKED PIXELS Visual : TRUECOLOR hombre pues para empezar puedes bajar el numero de colores por pixel ahora estas usando 4194304 para representar la pantalla si bajas esta cantidad el procesador tendra que mover menos informacion. Pues, dime como cambiar el numero de colores por pixel porque no encuentro la opcion Desde ya muchas gracias -- HLG aki salen todos los modos graficos: http://tldp.org/HOWTO/Framebuffer-HOWTO-5.html#ss5.3 puedes coger el 0x305 te ira 4 veces mas rapido -- La resistencia es fútil todos seréis asimilados
Re: VESA Framebuffer
On Tue, 31 Dec 2002 13:07:49 -0300 root [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Buenas. He leído y comprobado que el VESA FB es mucho mas lento que un famebuffer nativo de mi placa, pero, ya que la misma no me lo soporta, he usado el vesa FB. Ahora, nadie tiene tips sobre como acelerar el framebuffer? mi configuracion actual del mismo es: mode 1024x768-76 # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 16 timings 12714 128 32 16 4 128 4 rgba 5/11,6/5,5/0,0/0 endmode Frame buffer device information: Name: VESA VGA Address : 0xdc00 Size: 4194304 Type: PACKED PIXELS Visual : TRUECOLOR hombre pues para empezar puedes bajar el numero de colores por pixel ahora estas usando 4194304 para representar la pantalla si bajas esta cantidad el procesador tendra que mover menos informacion. XPanStep: 0 YPanStep: 0 YWrapStep : 0 LineLength : 2048 Accelerator : No Y otra pregunta, tal vez interesante, mingetty vs getty Osea, que me recomiendan, correr mi fb con getty o con su hnito menor mgetty? Desde ya Millones de gracias y feliz año nuevo. ### .:;i;::. ,jGGLjttjfGfi. . fGj; .tGG; :Lf.:,::. ;Gj jf i, Gt Li j . G, fi ji . :j: ;L:.;tii;i: jG: iL, .it,. :i: i: Hector Luis Gimbatti Linux Registered User: #241293 GnuPG Public Key = 1024D/283C4C96 ( http://pgp.mit.edu ) Key fingerprint = 0078 6DCA 21B3 6524 404E D9A4 1F24 9313 283C 4C96 Powered by: GNU/LINUX Debian ( Woody ) - Kernel 2.4.18-686 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE+EcDVHySTEyg8TJYRAgCiAJwOEy93hc3/SPKuawEezxHXTSJbrwCfRGbC E3wOe04nDaKwwhZXtyF0XGU= =eZsJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- La resistencia es fútil todos seréis asimilados
Re: VESA X-server for debian 3.0
On Tuesday 31 December 2002 02:50 pm, Larry Hunsicker wrote: Thanks to Marc Wilson for his suggestion. But we can't find the vesa X-server in the Debian package list. What should we be looking for? Again, thanks in advance for any help that you can give me. Larry Hunsicker In Woody,Xfree86 v4.x the xservers are all in one package, xserver-xfree86. You can reconfigure the package with: 'dpkg-reconfigure xserver-xfree86' and select the appropriate drivers from a list during config, there are vga vesa choices. In xfree86 v3.x the servers are separate packages. -- Greg Madden -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vesa and Framebuffer
On Fri, Dec 14, 2001 at 09:18:20AM -0500, [EMAIL PROTECTED] wrote: | Hi, | I try to run the woody kernel image 2.4.9-686 hoping to change the console | resolution from 680 to 1024x768. I know that i therefore need the vesa stuff | ... compiling the kernel souce 2.4.9 by myself with non-modular entries for | frambuffer and vega modes everything works fine with vga=791 on boot prompt | but not booting with the woody-kernel image 2.4.9-686 ...does anybody got | an idea ... Karsten thinks from reading the docs that on x86 platforms there should be no need to custom compile the framebuffer stuff in the kernel. However in my experience I needed to compile the kernel myself and enable the framebuffer for it to work. When you build your own kernel, I recommend first loading the stock kernel's config, then proceed to customize the config as you want (include the framebuffer at the very least). Then boot with the proper commandline arguments and it will be there (as you indicate you have managed to do successfully). HTH, -D -- There are six things the Lord hates, seven that are detestable to him : haughty eyes, a lying tongue, hands that shed innocent blood, a heart that devises wicked schemes, feet that are quick to rush into evil, a false witness who pours out lies and a man who stirs up dissension among brothers. Proverbs 6:16-19
Re: Vesa
Hello Luiken: Vesa and X have nothing to do with each other. If you have a vesa graphics card, I'm sure the appropriate drive will take full advantage of it. If you have a Vesa bus on your PC just make certain that the card you have is defined in the xf86config setup program. i.e. - ATI MACH 32 Pro Turbo Peter -Original Message- From: Luiken, Arijan [EMAIL PROTECTED] To: debian-user@lists.debian.org debian-user@lists.debian.org Date: August 10, 1998 5:50 AM Subject: Vesa Hi is there an x-server who supports vesa ? Greets, Arijan -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Vesa
- Hi is there an x-server who supports vesa ? you mean VL bus ? Xsewrvers support cards not busses... -- Matus fantomas Uhlar, sysadmin at NETLAB+ Kosice, Slovakia BIC coord for *.sk; admin of netlab.irc.sk; co-admin of irc.felk.cvut.cz
Re: Vesa
Luiken, Arijan wrote: Hi is there an x-server who supports vesa ? Greets, Arijan If you are talking about VESA graphics protocal, this isn't useful with X, since Xservers are written to interface directly with the graphics hardware on the video card. VESA was meant to provide a common API for DOS progs that could support VESA and thus run on many different video cards. This isn't needed with X, because the X system relies on 'servers' that can be written specifically for the video card's hardware. -- Ed C.
