Menu
▾
▴
linux-fbdev-users — Generic mailing list for users of frame buffers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(9) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(12) |
Feb
(10) |
Mar
|
Apr
(5) |
May
(3) |
Jun
|
Jul
(5) |
Aug
(7) |
Sep
(15) |
Oct
(4) |
Nov
(3) |
Dec
(7) |
| 2003 |
Jan
(5) |
Feb
(30) |
Mar
(5) |
Apr
(13) |
May
(12) |
Jun
(11) |
Jul
(1) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(7) |
| 2004 |
Jan
(4) |
Feb
(9) |
Mar
(16) |
Apr
(42) |
May
(5) |
Jun
(11) |
Jul
(3) |
Aug
(39) |
Sep
(5) |
Oct
(32) |
Nov
(27) |
Dec
|
| 2005 |
Jan
(11) |
Feb
(8) |
Mar
(22) |
Apr
(26) |
May
(9) |
Jun
(10) |
Jul
(7) |
Aug
(43) |
Sep
(23) |
Oct
(18) |
Nov
(15) |
Dec
(15) |
| 2006 |
Jan
(7) |
Feb
(16) |
Mar
(10) |
Apr
(1) |
May
(16) |
Jun
(8) |
Jul
(3) |
Aug
(35) |
Sep
(7) |
Oct
(4) |
Nov
(5) |
Dec
(1) |
| 2007 |
Jan
(2) |
Feb
(30) |
Mar
(6) |
Apr
(7) |
May
(5) |
Jun
|
Jul
(15) |
Aug
(12) |
Sep
(22) |
Oct
(48) |
Nov
(9) |
Dec
(7) |
| 2008 |
Jan
(3) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(4) |
Jun
(1) |
Jul
(5) |
Aug
(4) |
Sep
(4) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Jonas M. <jo...@fr...> - 2004-08-04 13:24:12
|
On 03/08/2004 Petr Vandrovec wrote: > ksymoops do not work on 2.6.x kernel. When you build 2.6.x kernel, you > have option (Kernel hacking -> Compile the kernel with debug info) to > store all symbols into kernel image, and then 2.6.x kernel will translate > oops from numbers to symbols for you, without any need for help from > ksymoops (and in this case your klogd should be started with option > '-x' or '-2'). ok, now i'm running a kernel with all debug info options set to kompile into kernel, and i run klogd with option '-x'. anyway, kern.log and syslog both stay quiet. can you give me further hints about where and how to find 2.6 debug information? bye jonas |
|
From: Jonas M. <jo...@fr...> - 2004-08-04 11:52:11
|
On 03/08/2004 Jonas Meurer wrote: > ok, i've done so, but now i'm running with mga compiled as module, and > automaticly mounted. first boot with this new kernel did work well ... anyway, using mga doesn't help anything. my system still sucks. > > Can you recheck that you have 'Option "UseFBDev" "true"' and > > 'Option "HWcursor" "off"' in the XFree config? > > both weren't in the config, but also aren't documented in XF86Config-4(5x) > anyway i've added them to "Device" section, and xfree86 still runs ok. > > we'll see if it helps. it doesn't. don't see any change with these options in the config. the only strange thing is, that i said 'use fb device' at configuration of debian's xserver-xfree86 package. maybe a bug. > > And for DRI I do not understand X code well enough to find where > > tests which should prevent X from hitting hardware should be added. do you mean that usually it shouldn't change anything? bye jonas |
|
From: Jonas M. <jo...@fr...> - 2004-08-03 16:55:51
|
On 03/08/2004 Petr Vandrovec wrote: > ksymoops do not work on 2.6.x kernel. When you build 2.6.x kernel, you > have option (Kernel hacking -> Compile the kernel with debug info) to > store all symbols into kernel image, and then 2.6.x kernel will translate > oops from numbers to symbols for you, without any need for help from > ksymoops (and in this case your klogd should be started with option > '-x' or '-2'). ok, i've done so, but now i'm running with mga compiled as module, and automaticly mounted. first boot with this new kernel did work well ... > Do you run 32bit or 64bit kernel? Strange thing is that while you > are in the X matroxfb is completely off. Did you tried booting > with 'video=matroxfb:disabled' to find whether it does not crash > without matroxfb too? Or try 'video=matroxfb:init' so matroxfb > initializes your video hardware from scratch, without relying on > BIOS doing its job correctly. Or try vesafb instead (if x86-64 supports > it). i'm running debian i386 port with 32bit kernel. i'll try with video=matroxfb:disabled and :init, and report. > Does it power off your box immediately, or after you hold it down for > 4 seconds? no, it shutdowns the system, like a 'shutdown -h now' or 'halt' would do. that's the function of the ACPI button module. > Can you recheck that you have 'Option "UseFBDev" "true"' and > 'Option "HWcursor" "off"' in the XFree config? both weren't in the config, but also aren't documented in XF86Config-4(5x) anyway i've added them to "Device" section, and xfree86 still runs ok. we'll see if it helps. > First three are fixed in my matroxfb patches (which you can use with > other drivers too - I use it with radeon on my notebook and with > vesafb on Parhelia on my other system). But as yesterday even full > removal of VT from kernel was proposed on LKML, chance to get these > changes in is pretty low. VT is virtual terminal? so how else will it be handled in future? is there a superior system? > And for DRI I do not understand X code well enough to find where > tests which should prevent X from hitting hardware should be added. mh, no idea how to say more. bye jonas |
|
From: Petr V. <VAN...@vc...> - 2004-08-03 11:26:14
|
On 3 Aug 04 at 13:09, Jonas Meurer wrote:
> On 03/08/2004 Petr Vandrovec wrote:
> > > i'll try to get an oops trace and some further debugging information.
> >
> > It would help a lot.
>
> sorry, it's harder than i even thought. as keyboard and screen are both
> frozen, i cannot lurk for console messages etc. and as i've no second
> machine, serial console is not possible.
>
> the logs are silent - they don't give any information:
> syslog has the boot logs, and directly afterwards the APCI button power
> off message, so nothing in the time where the freeze happened.
> XFree86.0.log.old ends with the successful startup of xdm, what finally
> causes the freeze. so no log information here too.
>
> and even kern.log doesn't give any information.
>
> and i don't understand ksymoops, when i execute it, it gives only:
> Error (regular_file): read_ksyms stat /proc/ksyms failed
> ksymoops: No such file or directory
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
ksymoops do not work on 2.6.x kernel. When you build 2.6.x kernel, you
have option (Kernel hacking -> Compile the kernel with debug info) to
store all symbols into kernel image, and then 2.6.x kernel will translate
oops from numbers to symbols for you, without any need for help from
ksymoops (and in this case your klogd should be started with option
'-x' or '-2').
> > In 2.4.x it was marked as EXPERIMENTAL only because nobody cared.
> > As driver is more than 5 years old, I think that I can say that it
> > is well tested now.
>
> full ack, but in my case the driver doesn't seem to be very stable.
> btw. i didn't have any problems with matroxfb until the athlon64 system
> with 2.6 kernel (all previous machines ran 2.4 kernels).
Do you run 32bit or 64bit kernel? Strange thing is that while you
are in the X matroxfb is completely off. Did you tried booting
with 'video=matroxfb:disabled' to find whether it does not crash
without matroxfb too? Or try 'video=matroxfb:init' so matroxfb
initializes your video hardware from scratch, without relying on
BIOS doing its job correctly. Or try vesafb instead (if x86-64 supports
it).
> system boots, xdm starts, and therefore starts xserver, login box pops
> up, you're able to input some chars, and then keyboard and screen
> are frozen.
> only APCI power off button still works to power off the system.
Does it power off your box immediately, or after you hold it down for
4 seconds?
> another scenario that happens sometimes: system boots, xdm starts,
> immediately after login box popped up, i change to tty1, move between
> all vc's (tty1-6 and tty8-12), do what i want, and sometimes, nevermind
> if 5minutes or 3hours later, switch back to tty7 (with xdm running), and
> during this switch, directly after showing a grey screen the first time,
> the freeze happens.
Can you recheck that you have 'Option "UseFBDev" "true"' and
'Option "HWcursor" "off"' in the XFree config?
> > Neither of these bugs are in the matroxfb - they are features of fbdev/fbcon
> > layer.
>
> so no plans to fix them?
First three are fixed in my matroxfb patches (which you can use with
other drivers too - I use it with radeon on my notebook and with
vesafb on Parhelia on my other system). But as yesterday even full
removal of VT from kernel was proposed on LKML, chance to get these
changes in is pretty low.
And for DRI I do not understand X code well enough to find where
tests which should prevent X from hitting hardware should be added.
Petr Vandrovec
|
|
From: Jonas M. <jo...@fr...> - 2004-08-03 11:09:38
|
On 03/08/2004 Petr Vandrovec wrote: > I did not found any bug descriptions in these articles. They are just > vaguely saying that 2.6.x is crap, without any explanation what > should be changed and why. sure, that's true, but i guess they are only from non-technical users, and thus not very usefull. > > i'll try to get an oops trace and some further debugging information. > > It would help a lot. sorry, it's harder than i even thought. as keyboard and screen are both frozen, i cannot lurk for console messages etc. and as i've no second machine, serial console is not possible. the logs are silent - they don't give any information: syslog has the boot logs, and directly afterwards the APCI button power off message, so nothing in the time where the freeze happened. XFree86.0.log.old ends with the successful startup of xdm, what finally causes the freeze. so no log information here too. and even kern.log doesn't give any information. and i don't understand ksymoops, when i execute it, it gives only: Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod don't know if ksymoops could help me in any way, but i've no further ideas about how to get debugging information. can you give me a hint? > > > > so you mean that you patch doesn't fix the bug? on irc in #kernelnewbies > > on irc.kernelnewbies.org i got the information, that your backport fixes > > at least this bug behaviour. but it might have been a liar, don't know. > > he also said, that matroxfb in 2.6 is very unstable while being > > distributed as stable. in 2.4 it was tagged as experimental. > > In 2.4.x it was marked as EXPERIMENTAL only because nobody cared. > As driver is more than 5 years old, I think that I can say that it > is well tested now. full ack, but in my case the driver doesn't seem to be very stable. btw. i didn't have any problems with matroxfb until the athlon64 system with 2.6 kernel (all previous machines ran 2.4 kernels). > I'm not aware about any problems with matroxfb in stock 2.6.x kernel. mh, very strange. to bear out the bug on software side, i tried out another g400, without dual head, and it shows exactly the same behaviour: system boots, xdm starts, and therefore starts xserver, login box pops up, you're able to input some chars, and then keyboard and screen are frozen. only APCI power off button still works to power off the system. another scenario that happens sometimes: system boots, xdm starts, immediately after login box popped up, i change to tty1, move between all vc's (tty1-6 and tty8-12), do what i want, and sometimes, nevermind if 5minutes or 3hours later, switch back to tty7 (with xdm running), and during this switch, directly after showing a grey screen the first time, the freeze happens. i'll try with dri enabled in kernel, maybe it changes anything on the situation. > There are four problems with matroxfb driver in 2.6.x kernel: > [...] > Neither of these bugs are in the matroxfb - they are features of fbdev/fbcon > layer. so no plans to fix them? > Only difference between matroxfb from platan.vc.cvut.cz, and one in > the kernel is that it supports text mode (-depth 0), and that some > PINS values are interpreted differently. Neither of these changes > can cause/fix crashes/lockups/... anyway i'll try with 2.7.8-rc2 to go sure. > But matroxfb from platan.vc.cvut.cz also comes with different fbcon, > which is more simillar to 2.4.x than to what 2.6.x offers (and which > fixes problems (2) and (3) above; (4) above is not kernel problem), > and while this may fix some other bugs I do not know about, it may > also introduce some other bugs you did not find yet. i'll check, and report. > But as I said, I'm not aware about any bugs in the matroxfb (last > famous words). we'll see, if this changes. bye jonas |
|
From: Petr V. <VAN...@vc...> - 2004-08-03 00:27:17
|
On 3 Aug 04 at 2:01, Jonas Meurer wrote: > sorry? i guess they belong to the same bug, but i'm no kernel developer. I did not found any bug descriptions in these articles. They are just vaguely saying that 2.6.x is crap, without any explanation what should be changed and why. > i'll try to get an oops trace and some further debugging information. It would help a lot. > > IRQ support is in both stock kernel and in my patches. Other two > > patches are not going to the driver. > > so you mean that you patch doesn't fix the bug? on irc in #kernelnewbies > on irc.kernelnewbies.org i got the information, that your backport fixes > at least this bug behaviour. but it might have been a liar, don't know. > he also said, that matroxfb in 2.6 is very unstable while being > distributed as stable. in 2.4 it was tagged as experimental. In 2.4.x it was marked as EXPERIMENTAL only because nobody cared. As driver is more than 5 years old, I think that I can say that it is well tested now. I'm not aware about any problems with matroxfb in stock 2.6.x kernel. There are four problems with matroxfb driver in 2.6.x kernel: (1) 2.6.x fbdev does not allow for native text mode; thus matroxfb in 2.6.x kernel does not offer text mode (fbset ... -depth 0). (2) 2.6.x fbdev does not store fb mode per-VT, but only one globally. So you may have troubles with setting each VT to different resolution. (3) 2.6.x fbcon's scrollback (and 2.4.x too, for that matter) crashes if you have more than one visible console, and you did not disable scrollback (recent 2.6.x "fixed" it indirectly by supporting only one visible console). (4) mga-dri reprograms accelerator from time to time even if X are not visible. This causes massive screen corruption if display resolution or color depth you use in X is different from one you use on the console, and occassional screen corruption if resolutions match. Neither of these bugs are in the matroxfb - they are features of fbdev/fbcon layer. Only difference between matroxfb from platan.vc.cvut.cz, and one in the kernel is that it supports text mode (-depth 0), and that some PINS values are interpreted differently. Neither of these changes can cause/fix crashes/lockups/... But matroxfb from platan.vc.cvut.cz also comes with different fbcon, which is more simillar to 2.4.x than to what 2.6.x offers (and which fixes problems (2) and (3) above; (4) above is not kernel problem), and while this may fix some other bugs I do not know about, it may also introduce some other bugs you did not find yet. But as I said, I'm not aware about any bugs in the matroxfb (last famous words). Best regards, Petr Vandrovec |
|
From: Jonas M. <jo...@fr...> - 2004-08-03 00:01:41
|
On 02/08/2004 Petr Vandrovec wrote: > Links below has nothing to do with your freeze, unless I missed something. sorry? i guess they belong to the same bug, but i'm no kernel developer. > Oopses trace, and so on... Also, if you have enabled DRI, ask DRI > developers... i don't have enabled dri, as i read that there might be problems with matroxfb, dri and x. i'll try to get an oops trace and some further debugging information. > IRQ support is in both stock kernel and in my patches. Other two > patches are not going to the driver. so you mean that you patch doesn't fix the bug? on irc in #kernelnewbies on irc.kernelnewbies.org i got the information, that your backport fixes at least this bug behaviour. but it might have been a liar, don't know. he also said, that matroxfb in 2.6 is very unstable while being distributed as stable. in 2.4 it was tagged as experimental. bye jonas |
|
From: Petr V. <VAN...@vc...> - 2004-08-02 20:39:51
|
On 2 Aug 04 at 21:59, Jonas Meurer wrote: > > What problem do you have, exactly? I'm not aware about any possible > > bugs in the kernel's code if you do not use more than one head. > > yea, everytime my system boots, the last boot action is starting xdm. > this starts the xserver, and after displaying the login box, keyboard > and screen freeze. the system is not frozen, as power off button with > apm support still shutdowns the system. > anyway, shutdown doesn't switch to normal virtual console, but shows a > screwed up grey screen, like default xdm background. Links below has nothing to do with your freeze, unless I missed something. Oopses trace, and so on... Also, if you have enabled DRI, ask DRI developers... > it would be great if you could fix this bug. links are: > http://www.directfb.org/mailinglists/directfb-users/2004/02-2004/msg00079.html IRQ support is in both stock kernel and in my patches. Other two patches are not going to the driver. > http://kerneltrap.org/node/view/1712 There are no useful data here. Petr Vandrovec |
|
From: Jonas M. <jo...@fr...> - 2004-08-02 19:59:52
|
On 02/08/2004 Petr Vandrovec wrote: > > which one is the correct one for my environment? > > Neither one. Only patch which will apply cleanly to the non-bitkeeper > versions from day when these patch were released is matroxfb-2.6.8-rc2, > which will apply to 2.6.8-rc2. There is no patch which can be applied to > pure 2.6.7. k. then i'll use this kernel. but it doesn't have all the debian packages. > What problem do you have, exactly? I'm not aware about any possible > bugs in the kernel's code if you do not use more than one head. yea, everytime my system boots, the last boot action is starting xdm. this starts the xserver, and after displaying the login box, keyboard and screen freeze. the system is not frozen, as power off button with apm support still shutdowns the system. anyway, shutdown doesn't switch to normal virtual console, but shows a screwed up grey screen, like default xdm background. hope to help ... it would be great if you could fix this bug. links are: http://www.directfb.org/mailinglists/directfb-users/2004/02-2004/msg00079.html http://kerneltrap.org/node/view/1712 bye jonas |
|
From: Petr V. <VAN...@vc...> - 2004-08-02 19:01:15
|
On 2 Aug 04 at 20:46, Jonas Meurer wrote:
> i've already read about similar problems, and that matroxfb maintainer
> provides backports for 2.6 kernels to 2.4 matroxfb.
>
> the problem is, that there are three patches for 2.6.7 available:
> matroxfb-2.6.7-c1784
> matroxfb-2.6.7-c1811
> matroxfb-2.6.7-c1849
>
> which one is the correct one for my environment?
Neither one. Only patch which will apply cleanly to the non-bitkeeper
versions from day when these patch were released is matroxfb-2.6.8-rc2,
which will apply to 2.6.8-rc2. There is no patch which can be applied to
pure 2.6.7.
> can you give me any further links, docs or hints?
What problem do you have, exactly? I'm not aware about any possible
bugs in the kernel's code if you do not use more than one head.
Best regards,
Petr Vandrovec
|
|
From: Jonas M. <jo...@fr...> - 2004-08-02 18:47:07
|
hi, i've troubles with matroxfb and kernel 2.6.7 when starting x. it sometimes freezes my keyboard and the screen. i've already read about similar problems, and that matroxfb maintainer provides backports for 2.6 kernels to 2.4 matroxfb. the problem is, that there are three patches for 2.6.7 available: matroxfb-2.6.7-c1784 matroxfb-2.6.7-c1811 matroxfb-2.6.7-c1849 which one is the correct one for my environment? i have 2.6.7 on a debian/linux i386 port, my hardware is a amd athlon64 with 512MB ram and matrox G400 dual head. can you give me any further links, docs or hints? bye jonas |
|
From: Torgeir V. <to...@po...> - 2004-07-08 11:34:42
|
On Fri, 2004-07-02 at 20:01 +0100, Torgeir Veimo wrote: > I am trying to configure a 1280x720 resolution at 50Hz with a radeon > 9100 QM card. Not much activity on this list? > I have set up a mode in fb.modes that works if I set it with fbset after > boot, but then the "usable" text area doesn't span the entire > resolution, only about half the width and twothird the height, and > positioned to the upper left. I fixed this by actually editing the macmodes.h file and including the timing for this particular mode and setting it as the default mode at boot time, but the timing seems a bit off. I only get correct timing if I run a fbset "1280x720-50" command after a boot. Are there any assumptions the radeonfb code does wrt to timings that I've missed? And why does the radeonfb driver use it's own mac specific timings? Is the old radeonfb driver better in this respect? -- Torgeir Veimo <to...@po...> |
|
From: Torgeir V. <to...@po...> - 2004-07-02 19:08:29
|
On Fri, 2004-07-02 at 20:01 +0100, Torgeir Veimo wrote: > I am trying to configure a 1280x720 resolution at 50Hz with a radeon > 9100 QM card. > /var/log/messages at boot time; And dmesg output, for completeness; radeonfb_pci_register BEGIN radeonfb: probed DDR SGRAM 131072k videoram radeonfb: mapped 16384k videoram radeonfb: Invalid ROM signature 0 should be 0xaa55 radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 4 (DVI-D) : 4200 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: Monitor 1 type CRT found radeonfb: Monitor 2 type no found radeonfb: ATI Radeon QM DDR SGRAM 128 MB radeonfb_pci_register END I am using the analog connector on this card, connected to a Sanyo PLV Z2 projector. It advertises wrong EDID data when in PC mode. I can only get it to advertise 1280x720 on the DVI port, but then I am restricted to 60Hz, to get a tearing free picture. This is why I am using the analogue port. -- Torgeir Veimo <to...@po...> |
|
From: Torgeir V. <to...@po...> - 2004-07-02 19:01:57
|
I am trying to configure a 1280x720 resolution at 50Hz with a radeon 9100 QM card. I have set up a mode in fb.modes that works if I set it with fbset after boot, but then the "usable" text area doesn't span the entire resolution, only about half the width and twothird the height, and positioned to the upper left. # 50 Hz mode "1280x720-50" # D: 61.80 MHz, H: 37.50 kHz, V: 50.00 Hz geometry 1280 720 1280 720 16 timings 16181 218 110 20 5 40 5 endmode When I try to use this mode at boot time, nothing happens. I have the following settings in grub.conf; title Fedora Core (2.6.5-1.308custom) root (hd0,2) kernel /boot/vmlinuz-2.6.5-1.308custom ro root=/dev/hda3 video=radeonfb:xres:1280,yres:720,depth:16,left:218,right:110,hslen:40, upper:20,lower:5,vslen:5,pixclock:16181 Any idea what I am doing wrong? I have both matroxfb and radeonfb compiled into the kernel. /var/log/messages at boot time; Jul 2 19:36:32 vigor13 kernel: isapnp: Scanning for PnP cards... Jul 2 19:36:32 vigor13 kernel: isapnp: No Plug & Play device found Jul 2 19:36:32 vigor13 kernel: hStart = 664, hEnd = 760, hTotal = 800 Jul 2 19:36:32 vigor13 kernel: vStart = 491, vEnd = 493, vTotal = 525 Jul 2 19:36:32 vigor13 kernel: h_total_disp = 0x4f0063^I hsync_strt_wid = 0x8c02a2 Jul 2 19:36:32 vigor13 rpcidmapd: rpc.idmapd startup succeeded Jul 2 19:36:32 vigor13 kernel: v_total_disp = 0x1df020c^I vsync_strt_wid = 0x8201ea Jul 2 19:36:32 vigor13 kernel: pixclock = 39721 Jul 2 19:36:32 vigor13 kernel: freq = 2517 Jul 2 19:36:32 vigor13 kernel: post div = 0x3 Jul 2 19:36:32 vigor13 kernel: fb_div = 0x59 Jul 2 19:36:32 vigor13 kernel: ppll_div_3 = 0x30059 Jul 2 19:36:32 vigor13 kernel: lvds_gen_cntl: 00000000 Jul 2 19:36:32 vigor13 kernel: Console: switching to colour frame buffer device 80x30 -- Torgeir Veimo <to...@po...> |
|
From: Jean D. <kh...@li...> - 2004-06-12 06:31:08
|
> thanks a lot, i'll try it. but how can i get the dot clock I use as > default in xfree86? Grep /var/log/XFree86.0.log (or whatever it's named for you) for lines like: (**) RADEON(0): Default mode "1024x768": 78.8 MHz, 60.1 kHz, 75.1 Hz (II) RADEON(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800 +hsync +vsync The first value (78.80) is the dot clock, in MHz. Alternatively, you can run "xvidtune" if you have that, and read the value after "Pixel Clock (MHz)". Hope that helps, -- Jean Delvare http://khali.linux-fr.org/ |
|
From: Jonas M. <jo...@fr...> - 2004-06-11 21:03:17
|
On 08/06/2004 Petr Vandrovec wrote: > > apart from all this inferesting stuff, my monitor starts to switch > > mode(?) or at least horizontal size, what means it sometimes starts to > > jump from normal view to another mode(?) or anything. anyway: the > > vertical size of screen stays like it was but the horizontal size of > > screen switchs, and thus left and right border of screen are not seen > > any longer but cutted by the hardware-border of my monitor. > > > > after some time of switching monitor stays in one of both view modes, > > but randomly jumps to and from from time to time. > > Probably picture size you are using is just on edge where monitor makes > decision which of its preset settings it should use. If it happens on > console, try changing pixclock a bit (it is first number in 'timmings' > entry in fbset output). If it happens in XFree, change dot clock in > /etc/X11/XF86Config-4... Usually change by 1% in either direction is more > than sufficient to get rid of this switching. Unless your monitor is dying... thanks a lot, i'll try it. but how can i get the dot clock I use as default in xfree86? bye jonas |
|
From: Geert U. <ge...@li...> - 2004-06-09 06:17:42
|
On Tue, 8 Jun 2004, Anselmo wrote:
> I've get the right form and clicked on send password button but didn't
> get the mail.
> I'm really sorry for the disease but it's about three weeks i'm trying
> to unsubscribe.
I unsubscribed you manually.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Petr V. <VAN...@vc...> - 2004-06-08 21:06:25
|
On 8 Jun 04 at 22:22, Jonas Meurer wrote:
> On 08/06/2004 Petr Vandrovec wrote:
> > I think that it is too drastic if you switched to fbdev driver. mga driver
> > with DRI disabled will be much faster.
>
> ah, good to know. so fbdev driver should only be used for old cards
> without good xfree86 support like vesa?
It usually depends how are xfree and kernel driver willing to coexist.
I tried to make kernel matroxfb as permissing as possible, but reprogramming
accelerator every second while some drawing operation is in progress is
really too much - so you cannot use DRI with matroxfb...
> > > yea, then my current configuration should work. Is DRI support a
> > > recommented feature for better performance/lookout/...?
> >
> > DRI is mainly for 3D performance.
>
> so i'm not able to run software with 3D usage like tuxracer ,what I
> didn't manage to do anyway since my system simply freezes at running
> tuxracer 0.61, and all these nice xmms visualisation plugins that
> freezed my system too a couple of times?
You should have no crashes without DRI...
> By the way, why did they freeze the system? doesn't this happen any
> longer without dri support, maybe in favour of just printing an error
> message?
... ah, I see that you found it already. They do not print any message
because your system is dead. If you have computer newer than 4 years, you'll
find that you also cannot power off box by simple pressing poweroff button -
- you have to hold it 4 secs.
Why it crashes is question for XFree people. With older XFree's they
did not set up AGP properly, and did not handle IRQs from videocard right,
but with XFree 4.3 I thought that all these problems were fixed.
> apart from all this inferesting stuff, my monitor starts to switch
> mode(?) or at least horizontal size, what means it sometimes starts to
> jump from normal view to another mode(?) or anything. anyway: the
> vertical size of screen stays like it was but the horizontal size of
> screen switchs, and thus left and right border of screen are not seen
> any longer but cutted by the hardware-border of my monitor.
>
> after some time of switching monitor stays in one of both view modes,
> but randomly jumps to and from from time to time.
Probably picture size you are using is just on edge where monitor makes
decision which of its preset settings it should use. If it happens on
console, try changing pixclock a bit (it is first number in 'timmings'
entry in fbset output). If it happens in XFree, change dot clock in
/etc/X11/XF86Config-4... Usually change by 1% in either direction is more
than sufficient to get rid of this switching. Unless your monitor is dying...
Petr
|
|
From: Anselmo <kh...@ti...> - 2004-06-08 20:57:49
|
Jan-Benedict Glaw wrote: >On Tue, 2004-06-08 21:01:09 +0200, Anselmo <kh...@ti...> >wrote in message <40C...@ti...>: > > >>Sorry but i'cant use the online form to unsubscribe. I get every time >>some errors. >> >> > >What error do you get there? > >MfG, JBG > > > I've get the right form and clicked on send password button but didn't get the mail. I'm really sorry for the disease but it's about three weeks i'm trying to unsubscribe. |
|
From: Jonas M. <jo...@fr...> - 2004-06-08 20:24:14
|
On 08/06/2004 Petr Vandrovec wrote: > I think that it is too drastic if you switched to fbdev driver. mga driver > with DRI disabled will be much faster. ah, good to know. so fbdev driver should only be used for old cards without good xfree86 support like vesa? > > yea, then my current configuration should work. Is DRI support a > > recommented feature for better performance/lookout/...? > > DRI is mainly for 3D performance. so i'm not able to run software with 3D usage like tuxracer ,what I didn't manage to do anyway since my system simply freezes at running tuxracer 0.61, and all these nice xmms visualisation plugins that freezed my system too a couple of times? By the way, why did they freeze the system? doesn't this happen any longer without dri support, maybe in favour of just printing an error message? > As helptext says, if you have G100, G200 or G400, you can toss a coin. If you > have ~8KB free memory, or if you plan upgrade to G450/G550, select G100-G550 > driver. If you have G400, and you are ABSOLUTELY sure that you'll rebuild > your kernel with G450/G550 support BEFORE plugging G450 into the box, > you can select G100-G400 choice, but I recommend it only for embeded box > where you do not plan any upgrade. (Main problem is that G400 and G450 > use same PCI device ID while they are completely different - G400 driver > will drive G450 as G400 - and so very bad things happen... hopefully > your monitor switches itself off when driven with 300Hz vertical sync) wow, thanks for great information! apart from all this inferesting stuff, my monitor starts to switch mode(?) or at least horizontal size, what means it sometimes starts to jump from normal view to another mode(?) or anything. anyway: the vertical size of screen stays like it was but the horizontal size of screen switchs, and thus left and right border of screen are not seen any longer but cutted by the hardware-border of my monitor. after some time of switching monitor stays in one of both view modes, but randomly jumps to and from from time to time. any idea what causes these troubles? is it more a software problem, or is my monitor broken? bye jonas |
|
From: Jan-Benedict G. <jb...@lu...> - 2004-06-08 19:25:37
|
On Tue, 2004-06-08 21:01:09 +0200, Anselmo <kh...@ti...>
wrote in message <40C...@ti...>:
> Sorry but i'cant use the online form to unsubscribe. I get every time=20
> some errors.
What error do you get there?
MfG, JBG
--=20
Jan-Benedict Glaw jb...@lu... . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B=FCrger" | im Internet! | im Ira=
k!
ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC=
PA));
|
|
From: Anselmo <kh...@ti...> - 2004-06-08 19:01:22
|
Sorry but i'cant use the online form to unsubscribe. I get every time some errors. Please unsubscribe me from the users list "lin...@li...". My address is kh...@ti.... Tank's |
|
From: Petr V. <VAN...@vc...> - 2004-06-08 18:42:20
|
On 8 Jun 04 at 16:03, Jonas Meurer wrote:
> > (depends on seconds being displayed or not), but other apps running
> > in your X can trigger that too.
>
> oh, so i used DRI in X until now, with the XFree86 mga driver, both
> enabled in kernel and XF86Config.
> I use fb driver for X now, and no DRI support any longer. Let's see if
> the problems stay away now.
I think that it is too drastic if you switched to fbdev driver. mga driver
with DRI disabled will be much faster.
> > Only 100% fix is to stop using DRI, or disabling acceleration on console
> > (fbset -accel false). Or you can just decrease likelihood of corruption
> > by using same color depth and same resolution in both X and on the console -
> > then usually only one line on screen gets printed with wrong color from
> > time to time instead of massive corruption.
>
> yea, then my current configuration should work. Is DRI support a
> recommented feature for better performance/lookout/...?
DRI is mainly for 3D performance.
> and what about these two matroxfb drivers in kernel 2.6.6, one for
> G100/G200/G400/G450/G550, and the other only for G100/G200/G400.
>
> I failed to get any information about which one to use for my G400.
> what's the difference of these drivers?
As helptext says, if you have G100, G200 or G400, you can toss a coin. If you
have ~8KB free memory, or if you plan upgrade to G450/G550, select G100-G550
driver. If you have G400, and you are ABSOLUTELY sure that you'll rebuild
your kernel with G450/G550 support BEFORE plugging G450 into the box,
you can select G100-G400 choice, but I recommend it only for embeded box
where you do not plan any upgrade. (Main problem is that G400 and G450
use same PCI device ID while they are completely different - G400 driver
will drive G450 as G400 - and so very bad things happen... hopefully
your monitor switches itself off when driven with 300Hz vertical sync)
Petr
|
|
From: Jonas M. <jo...@fr...> - 2004-06-08 14:02:59
|
On 05/06/2004 Petr Vandrovec wrote: > Are not you using DRI in X by any chance? When mga_dri is used, it > reprograms accelerator's line length, color depth, foreground and background > color (and other not so important registers) every now and then - gnome > clock applet is known to trigger it either once a minute or once a second > (depends on seconds being displayed or not), but other apps running > in your X can trigger that too. oh, so i used DRI in X until now, with the XFree86 mga driver, both enabled in kernel and XF86Config. I use fb driver for X now, and no DRI support any longer. Let's see if the problems stay away now. > Only 100% fix is to stop using DRI, or disabling acceleration on console > (fbset -accel false). Or you can just decrease likelihood of corruption > by using same color depth and same resolution in both X and on the console - > then usually only one line on screen gets printed with wrong color from > time to time instead of massive corruption. yea, then my current configuration should work. Is DRI support a recommented feature for better performance/lookout/...? and what about these two matroxfb drivers in kernel 2.6.6, one for G100/G200/G400/G450/G550, and the other only for G100/G200/G400. I failed to get any information about which one to use for my G400. what's the difference of these drivers? bye jonas |
|
From: Petr V. <VAN...@vc...> - 2004-06-04 23:33:06
|
On 29 May 04 at 15:09, Jonas Meurer wrote:
>
> The screen generally is unreadable after one new lineprint, what makes
> pagers, editors etc unusable. The screen only gets refreshed correctly,
> if I change to another tty.
> After working in X for some time, the problem sometimes vanishes and
> comes back after some time staying on the virtual consoles (tty).
Are not you using DRI in X by any chance? When mga_dri is used, it
reprograms accelerator's line length, color depth, foreground and background
color (and other not so important registers) every now and then - gnome
clock applet is known to trigger it either once a minute or once a second
(depends on seconds being displayed or not), but other apps running
in your X can trigger that too.
Only 100% fix is to stop using DRI, or disabling acceleration on console
(fbset -accel false). Or you can just decrease likelihood of corruption
by using same color depth and same resolution in both X and on the console -
then usually only one line on screen gets printed with wrong color from
time to time instead of massive corruption.
Petr
|
6 messages has been excluded from this view by a project administrator.
