View previous topic :: View next topic |
Author |
Message |
Config Retired Dev
Joined: 25 May 2003 Posts: 187 Location: Zurich, Switzerland
|
Posted: Sat Aug 02, 2003 12:54 pm Post subject: |
|
|
lucida wrote: | Config wrote: | But doesn't the radeon have its own framebuffer driver - a hardware accelerated one? |
but...
1. On 2.6, I can't make it work. I always get 640x480@60 with radeonfb.
2. On 2.4, I can't make it work with mplayer.
not mentioning the crappy cursor. |
I can't make it work under 2.6 either (well, I can use the framebuffer, but bootsplash doesn't work.
mplayer? I compiled it with svga and directb, fbcon, and I can run any movie with mplayer -vo svga <filename>.... _________________ Config - caught by a chronic disease called tuxmania.... |
|
Back to top |
|
|
viperlin Veteran
Joined: 15 Apr 2003 Posts: 1319 Location: UK
|
Posted: Sat Aug 02, 2003 2:00 pm Post subject: |
|
|
ok just feedback:
kernel: 2.4.20 vanilla with bootsplash patches and loopAES.
graphics card: Geforce 4 MX440
Monitor: Compaq MV920
works fine.
and thanks for bringing this to my attention, the flickering was annoying. |
|
Back to top |
|
|
Config Retired Dev
Joined: 25 May 2003 Posts: 187 Location: Zurich, Switzerland
|
Posted: Sun Aug 03, 2003 10:18 am Post subject: |
|
|
I just looked at the 2.6.0-test2 kernel vesafb.c, and it looks a lot different - so I don't think the patch would work _________________ Config - caught by a chronic disease called tuxmania.... |
|
Back to top |
|
|
FormerSlacker Guru
Joined: 11 Mar 2003 Posts: 340 Location: Toronto, ON. Canada
|
Posted: Sun Aug 03, 2003 10:49 am Post subject: |
|
|
Another success story. I've got my bootsplashed vesafb console running at 1024x768 @ 80hz!
Kernel: 2.4.21 vanilla with bootsplash and i2c patches
Video Card: Geforce 2 GTS
I had to use the output of xvidtune to configure the vesa header file. The supplied perl script worked, but the picture was shifted to the left side of the monitor (I probably put in the wrong values ).
Aside from that, it works perfectly it seems
Thanks alot spock! |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Sun Aug 03, 2003 1:01 pm Post subject: |
|
|
As to 2.6.0-test2, there is nothing to think about, since the patch has already been tested with this kernel and has proven to work as well as it does with 2.4.x The thing is - the patch itself has actually nothing to do with vesafb.c. While vesafb.c is the main part of VESA framebuffer driver, the switch from standard 80x25 text mode to selected VESA graphic mode takes place at boot time, while the CPU is still in real mode. My patch alters video.S code, allowing the user to select a "modified" mode with the refresh rate he/she chooses. |
|
Back to top |
|
|
Config Retired Dev
Joined: 25 May 2003 Posts: 187 Location: Zurich, Switzerland
|
Posted: Sun Aug 03, 2003 1:07 pm Post subject: |
|
|
Uh... I'm stupid
I didn't even check which file gets patched - I'll try it out as soon as possibel _________________ Config - caught by a chronic disease called tuxmania.... |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Sun Aug 03, 2003 1:40 pm Post subject: |
|
|
Have fun with it Just patch the kernel-tree and copy your vesafb_modes.h file to make it as painless as possible |
|
Back to top |
|
|
pYrania Retired Dev
Joined: 27 Oct 2002 Posts: 650 Location: Cologne - Germany
|
Posted: Sun Aug 03, 2003 1:46 pm Post subject: |
|
|
my monitor gets out of sync when trying it. I'm pretty sure the bandwith documented in the monitors manual is wrong.
max. horizontal: 98 kHz
max. vertical: 120 Hz
Bandwith: 202,5 MHz
any idea? _________________ Markus Nigbur |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Sun Aug 03, 2003 1:51 pm Post subject: |
|
|
Try setting the bandwidth to lower values - smth like 150MHz or even 125 or 100 MHz. Making max. vert. 115 Hz and max. horiz. 95 won't hurt either. If nothing helps, forget about the script, start X with the resolution you use on console, run xvidtune and copy the values to /usr/src/linux/arch/i386/boot/vesafb_modes.h as described in README and earlier in this thread. |
|
Back to top |
|
|
LinuxDolt Tux's lil' helper
Joined: 05 May 2003 Posts: 104
|
Posted: Sun Aug 03, 2003 2:18 pm Post subject: |
|
|
is the file linked to in the beginning of the thread being kept recent? maybe you ought to start using some form of versioning and make an ebuild for it too... it sure wouldn't hurt
i am just wondering because i've noticed you've been patching the patch so to speak during the duration of this threads life... |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Sun Aug 03, 2003 3:07 pm Post subject: |
|
|
The only thing that was changed during this thread's existence is the configuration script. The old version used dialog and at some point I came to the conclusion that it's not really necessary - and so I changed it. The core assembly code hasn't changed a bit. So - the link at the beginning of the thread still points to the current version. Shall there be any non-trivial modifications to the patch - I will make sure versioning is included
As to the ebulld - I'm not sure it would make any sense since what its function would be just to download the patch and patch /usr/src/linux. However, if you think having an ebuild for it would be nice, I can and will make one and submit it to the bugzilla system as soon as I finish a few other ebuilds I wish to contribute |
|
Back to top |
|
|
schlehmil Tux's lil' helper
Joined: 19 Apr 2003 Posts: 110 Location: Berlin, Germany
|
Posted: Sun Aug 03, 2003 4:53 pm Post subject: |
|
|
thanks a lot spock_
this patch is working well for me with 1024x768@100hz. |
|
Back to top |
|
|
Cicero Apprentice
Joined: 21 Jul 2003 Posts: 220
|
Posted: Sun Aug 03, 2003 5:40 pm Post subject: |
|
|
Eediot wrote: |
thank you!! I got this to work on a GF ti4200, linux-2.4.20-gentoo-r5. Well worth the reboots. I get 85hz at 1024x768. the tough part was getting the vesafb_modes.h set right, the default was off center by an inch, eventually I ran xvidtune and copied the settings into vesafb_modes.h using the discription there.
|
Exact same experience here. Possibly a bug in the script's calculations? It's something small, as the numbers were not off by much, but none of them exactly matched xvidtune's output. I don't know how everything is calculated, so I can't help .
Except for that, everything went flawlessly. I can stare at my purty bootsplash now (thanks to the >1GB patch) and not have my eyes bleed. Thanks! |
|
Back to top |
|
|
Blurpy Tux's lil' helper
Joined: 11 Feb 2003 Posts: 111 Location: Norway
|
Posted: Mon Aug 04, 2003 11:58 am Post subject: |
|
|
This is great! I'm now running a vesa framebuffer at 1024x768@90hz. I tried to get 85hz, and it somehow became 90hz. It doesn't matter as my monitor can handle it.
I did it the manual way with xvidtune, on a vanilla kernel. Finally no more 60hz and headache |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Mon Aug 04, 2003 5:53 pm Post subject: |
|
|
Hmm.. it seems the script really needs some 'adjustments'. I'll try to do something about it. If you wish to help, please send me (in a PM or to my e-mail account) the correct ModeLine from xvidtune/XFree86 config file and input data you used (max. vert., max. horiz., max. band.) or vesafb_modes.h the script generated.
I will also delay posting the patch to LKML until I'm able to find a better CRTC calculation routine or determine that one cannot be written |
|
Back to top |
|
|
LinuxDolt Tux's lil' helper
Joined: 05 May 2003 Posts: 104
|
Posted: Tue Aug 05, 2003 6:43 am Post subject: |
|
|
spock:
i personally do not know anything about doing the actual code, however, you may want to take a look at the following page, i find that it's routine is quite accurate for finding x modelines... i'm not sure about the conversion to svga fields however... this is just my attempt at being helpful for a project that looks VERY promising to me, if i am completely off, then may the powers that be correct me for it (namely you obviously)...
http://koala.ilog.fr/cgi-bin/nph-colas-modelines |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Tue Aug 05, 2003 8:13 am Post subject: |
|
|
The modeline counting part of my script is almost a direct 'fscking Lisp' to Perl conversion of the routine you pointed to (yeah, I know, Lisp might be great when it comes to AI, but doing some VESA calculations is nothing like AI and Perl is just great for almost everything ). So not only you are completely off, you are very accurate.
If Colas' routine does work for you and my script doesn't, please let me know (an error in conversion?). |
|
Back to top |
|
|
LinuxDolt Tux's lil' helper
Joined: 05 May 2003 Posts: 104
|
Posted: Tue Aug 05, 2003 8:24 am Post subject: |
|
|
spock_ wrote: | If Colas' routine does work for you and my script doesn't, please let me know (an error in conversion?). | well... i haven't exactly gotten around to using yours with the full capabilities of my hardware (i am capable of 90 rr at 1280x1024 but only targeted 85 in yours)
maybe i'll give my kernel another recompilation and see if feeding it some more stressing/less conservative data does ok... i'll leave ya know my findings... i just spend a heck of a lot more time in x than in console, so my x rr matters a little more than my console rr, and i didn't want to risk borking my vesa support... |
|
Back to top |
|
|
Blurpy Tux's lil' helper
Joined: 11 Feb 2003 Posts: 111 Location: Norway
|
Posted: Tue Aug 05, 2003 11:37 am Post subject: |
|
|
I just noticed that my cdroms doesn't work anymore when using the patched kernel. There is no /dev/cdroms/cdrom[0,1] anymore, and /dev/scsi is also gone. But if I boot an unpatched kernel they are back. I have not changed anything in the kernel config, so the only difference is the refresh rate patch.
Have anyone else noticed this? |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Tue Aug 05, 2003 1:06 pm Post subject: |
|
|
It's very improbable that the patch changes devfs behaviour in any way. Any modifications that are being made do not even come close to the devfs code. Try reversing the patch on an already patched tree and then compile the kernel without making any changes to your configuration. If this makes cdrom and scsi reappear, please tell me what kernel version are you using and what your hardware is (cpu, video card, cdrom). |
|
Back to top |
|
|
Blurpy Tux's lil' helper
Joined: 11 Feb 2003 Posts: 111 Location: Norway
|
Posted: Tue Aug 05, 2003 3:53 pm Post subject: |
|
|
How do I reverse the patch? |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Tue Aug 05, 2003 4:07 pm Post subject: |
|
|
The same way you applied it Just do:
Code: | bzip2 -dc patch-2.4.x-vesafb-rrc.bz2 | patch -p1 | and patch should ask if you want to reverse the patch. If somehow this doesn't work, you could enforce it, by adding '-R':
Code: | bzip2 -dc patch-2.4.x-vesafb-rrc.bz2 | patch -p1 -R |
|
|
Back to top |
|
|
Blurpy Tux's lil' helper
Joined: 11 Feb 2003 Posts: 111 Location: Norway
|
Posted: Tue Aug 05, 2003 7:17 pm Post subject: |
|
|
I did a make mrproper, and it seemed to fix it. It's working now. |
|
Back to top |
|
|
spock_ Retired Dev
Joined: 13 Jun 2003 Posts: 84 Location: Poland, Earth
|
Posted: Tue Aug 05, 2003 7:34 pm Post subject: |
|
|
Nice, I knew the patch have nothing to do with it
If you can, please msg me with your proper modelines and result from vesafb_mode_gen,pl. So far only Cicero has sent me some data. Without more info I will probably not be able to make any corrections. Come on, don't be too egoistic, you might have had to configure everything by hand, but let's just make it a little easier for the ones who will be using this in the future |
|
Back to top |
|
|
b3rT n00b
Joined: 09 Jun 2003 Posts: 71 Location: Germany
|
Posted: Wed Aug 06, 2003 1:15 pm Post subject: |
|
|
another tip: if you are using lilo it could be nessesary to write the vga-value not as hex but as decimal (espectially with older lilo-versions).
btw: works great...thx |
|
Back to top |
|
|
|