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 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 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 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 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 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 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, 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 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 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 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 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 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, 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, 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 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 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 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, 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, 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 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 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 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 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
