Hi,
I am a newcomer to the list so please forgive any unforgivable mistake I may do.
The problem at hand is savagefb. The specific model is 0x5333:0x8d01 (twisterP).
I am using a recent enough kernel and I am trying to use fb through SDL.
I believe SDL is not the problem because one of the monitors I tried it is
an EIZO FlexScan 520 that has the extremely nice feature to report the freequency
of the signals the graphics adaptor emits.
See the table:
640x480 800x600 1024x768
bpp 8 23.1/28.7 26.8/33.2 48.3/59.9 (works)
bpp 16 18.6/23.1 26.8/33.2 33.2/41.2
bpp 32 18.6/23.1 29.7/36.8 33.2/41.2
That means that 640x480x8 emits Horizontal sync at 23.1KHz / VF 28.Hz
which is out of the sync range of any monitor. So the savage clocks are
not programmed correctly (sorry for awkard use of terminology but I am
hardly a graphics expert).
As a workaround for my EIZO I tried (succesfully)
#This syncronize at 100Hz vertical refresh rate
#fbset -xres 640 -yres 480 -depth 16 -t 9260 48 16 33 10 96 2
#This syncronize at 60Hz vertical refresh rate (fbset -i repors 160Hz)
fbset -xres 640 -yres 480 -depth 16 -t 15385 48 16 33 10 96 2
This is not working for my other monitor a TFT Medion (1280x1024). So
I guess that makes it an EDID dependent bug.
So I tried to look the X source code. Looks like it is from the same
codebase more or less with the in kernel savage driver. However the
X driver supports the Option UseBios for mode switching. The default
setting is yes. I tried to disable it and bingo. X exhibits similar
behaviour to the FB driver. It programs the clocks like above. (more or less
I didn't try all the combinations).
So AFAIU neither kernel nor X knows how to program the specific savage card.
I would like it to debug it further but I don't know from where to start.
The code is nicely written but incomprehensible if you don't have the
manual in order to see what all these registers do.
I know howto patch/compile/test and I am willing to help with this if
there is somebody which can guide me a little bit.
.bill
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
The problem at hand is savagefb. The specific model is 0x5333:0x8d01 (twisterP).
I am using a recent enough kernel and I am trying to use fb through SDL.
[snip]
Any ideas on how should I proceed to make the S3 savage work with my monitors,
and preferably with any monitor?
For example since X / Bios combination works is it possible to get into the right
mode and then dump the registers somehow for examination or for later feeding?
Is it possible for the kernel driver to use Bios switching?
Any help / suggestion is greatly appreciated.
.bill
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-05-23 21:43:27
Vassilis Virvilis wrote:
Vassilis Virvilis wrote:
quoted
Hi,
quoted
The problem at hand is savagefb. The specific model is 0x5333:0x8d01
(twisterP).
I am using a recent enough kernel and I am trying to use fb through SDL.
[snip]
Any ideas on how should I proceed to make the S3 savage work with my
monitors,
and preferably with any monitor?
For example since X / Bios combination works is it possible to get into
the right
mode and then dump the registers somehow for examination or for later
feeding?
If you can somehow dump the registers of the working and non-working mode,
we might be able find a pattern.
If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.
Is it possible for the kernel driver to use Bios switching?
Currently, no.
Tony
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
If you can somehow dump the registers of the working and non-working mode,
we might be able find a pattern.
If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.
quoted
Is it possible for the kernel driver to use Bios switching?
Currently, no.
Vassilis,
Try http://dev.gentoo.org/~spock/projects/vesafb-tng/ for a
vesafb that supports bios mode switching and dump the regs
if it works for you.
cu,
Knut
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
Vassilis Virvilis wrote:
If you can somehow dump the registers of the working and non-working mode,
we might be able find a pattern.
If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.
Thanks for answering...
No I don't know how to dump the registers. I have been googling for that but
so I saw no light. Please dos send me/point to the utility.
When I have enough info I will post it here with the output of dccprobe.
.bill
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
Knut, thanks for answering...
I can use X to set the mode. X driver uses BIOS unless told
otherwise (UseBios = false) so the two solutions should be
equivalent. If this fails I will try vesafb-tng.
.bill
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
If you can somehow dump the registers of the working and non-working mode,
we might be able find a pattern.
If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.
I found dumpreg from the svgalib distribution (svgalib-bin in debian). Is this
sufficient? If not could you please send me the userspace utility you mentioned
the other day?
Thanks in advance.
.bill
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-05-27 09:27:06
Vassilis Virvilis wrote:
Antonino A. Daplas wrote:
quoted
If you can somehow dump the registers of the working and non-working
mode,
we might be able find a pattern.
If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.
I found dumpreg from the svgalib distribution (svgalib-bin in debian).
Is this
sufficient?
It might not be sufficient as it won't be able to recognize savage extended
VGA registers.
If not could you please send me the userspace utility you
mentioned
the other day?
Ok, attached, it's a quick hack. Before using it open the file savagedump.c
and look for the following defines:
#define PCI_ID 0x8d04 /* put the PCI id of the device here */
#define PCI_PBASE 0xdfe80000 /* put the start address of the PCI resource here */
and replace the above values with your own. First do "lspci -n | grep "Class 0300"
and you'll get something like this:
01:00.0 Class 0300: 5333:8d04
Use the last 4 digit ID for the PCI_ID (ie 8d04):
Then do lspci -v -n 5333:8d04 (using instead the vendor:device that you got) and you
should get something like this:
01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] (prog-if 00 [VGA])
Subsystem: Asustek Computer, Inc.: Unknown device 807b
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
Memory at dfe80000 (32-bit, non-prefetchable) [size=512K]
Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at dfe70000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities: [80] AGP version 2.0
Look for the (32-bit, non-prefetchable) string, the 32-bit hex number is what you're going
to use for your PCI_PBASE.
Once you've done all of the above, compile the app:
gcc -o savagedump savagedump.c
You can now run savagedump as root inside X or the console. Better if you run it in xterm
with X at different modes and with "UseBIOS" set to True and False.
./savagedump > /tmp/savagedump.txt
Send me the files you got, or you may examine it on your own to find a pattern.
Tony
PS: This utility dumps only the CRTC and Sequencer registers. Hopefully that's enough.
If not, we can revise it so it dumps all registers.
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-05-27 09:29:42
Antonino A. Daplas wrote:
Vassilis Virvilis wrote:
quoted
Antonino A. Daplas wrote:
quoted
If you can somehow dump the registers of the working and non-working
mode,
we might be able find a pattern.
If you don't know how to dump the register contents, let me know and I'll
send you a userspace utility to do that.
I found dumpreg from the svgalib distribution (svgalib-bin in debian).
Is this
sufficient?
It might not be sufficient as it won't be able to recognize savage extended
VGA registers.
quoted
If not could you please send me the userspace utility you
mentioned
the other day?
Ok, attached, it's a quick hack. Before using it open the file savagedump.c
and look for the following defines:
#define PCI_ID 0x8d04 /* put the PCI id of the device here */
#define PCI_PBASE 0xdfe80000 /* put the start address of the PCI resource here */
and replace the above values with your own. First do "lspci -n | grep "Class 0300"
and you'll get something like this:
01:00.0 Class 0300: 5333:8d04
Use the last 4 digit ID for the PCI_ID (ie 8d04):
Then do lspci -v -n 5333:8d04 (using instead the vendor:device that you got) and you
Typo. I meant
lspci -v -d 5333:8d04
Tony
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-05-29 00:14:08
Vassilis Virvilis wrote:
Antonino A. Daplas wrote:
quoted
lspci -v -d 5333:8d04
OK I have done a lot of tests. First my device is
5333:8d01 and the non-prefetchable memory is at ec000000
so we have
#define PCI_ID 0x8d01 /* put the PCI id of the device here */
#define PCI_PBASE 0xec000000 /* put the start address of the PCI
resource here */
Ok. I tried both X (with use bios), and SDL testsprite in 640x480,
800x600, 1024x768 at
8, 16, 24 bpp.
testsprite is a SDL demo that accepts the following options
(-width, -height, -bpp). I made both sets of tests in a medion TFT 18
screen and in an
EIZO F520 CRT.
All X modes are working.
SDL works for 1024x768 bpp=* in CRT and TFT
SDL work in 800x600 bpp={16, 24} (not 8bpp) only in TFT and __not in CRT__
I am attaching the output of savagedump for all modes, for both monitors
(#36),
just for future reference.
I will try to understand the differences but the registers are too many
and without
documentation it is a bit hopeless I am afraid. Or is there
Too many differences since the timings for the 2 modes are also different.
If you can match the timings, as shown by fbset and xvidtune, this should
minimize the variation.
documentation somewhere publicly
available?
There are no docs.
Is there any way to replay the working set of registers to get the
correct mode settings?
savagefb does save the initial registers and reuses part of them when setting
the mode, so if you can boot with vga= parameter that matches the initial mode
of savagefb, it might help. Try this:
video=savagefb:1024x768-16@60 vga=0x317
Tony
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
Too many differences since the timings for the 2 modes are also different.
If you can match the timings, as shown by fbset and xvidtune, this should
minimize the variation.
[snip]
savagefb does save the initial registers and reuses part of them when setting
the mode, so if you can boot with vga= parameter that matches the initial mode
of savagefb, it might help. Try this:
video=savagefb:1024x768-16@60 vga=0x317
thanks for the hand holding.
Let me reiterate to make sure I understood correctly.
Let's concentrate in one mode because trying all the modes is very time consuming.
Since I am interested mainly in 640x480-16@xx that means vga=0x311. That also
means I shouldn't fiddle with SVGATextMode before loading the savagefb driver.
Right now I am doing a lot of mode3; SVGATextMode -x to restore the console.
So I am booting with video=savagefb:640x480-16@60 vga=0x317 and prevent
SVGATextMode from running.
Now for mode setting. I will run X, xvidtune, fetch the mode. I will use
http://www.tldp.org/HOWTO/Framebuffer-HOWTO-18.html
instructions to convert the mode to a line fbset understands. Then
I will force my SDL test app to use the mode previously set by fbset
and then I will run the savagedump to compare with the X dump.
I will try the procedure above ASAP and report back unless you have any
objections in the methodology.
.bill
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2006-05-29 21:24:00
Vassilis Virvilis wrote:
Antonino A. Daplas wrote:
quoted
Too many differences since the timings for the 2 modes are also
different.
If you can match the timings, as shown by fbset and xvidtune, this should
minimize the variation.
[snip]
quoted
savagefb does save the initial registers and reuses part of them when
setting
the mode, so if you can boot with vga= parameter that matches the
initial mode
of savagefb, it might help. Try this:
video=savagefb:1024x768-16@60 vga=0x317
thanks for the hand holding.
Let me reiterate to make sure I understood correctly.
Let's concentrate in one mode because trying all the modes is very time
consuming.
Since I am interested mainly in 640x480-16@xx that means vga=0x311. That
also
means I shouldn't fiddle with SVGATextMode before loading the savagefb
driver.
Right now I am doing a lot of mode3; SVGATextMode -x to restore the
console.
So I am booting with video=savagefb:640x480-16@60 vga=0x317 and prevent
SVGATextMode from running.
Now for mode setting. I will run X, xvidtune, fetch the mode. I will use
http://www.tldp.org/HOWTO/Framebuffer-HOWTO-18.html
instructions to convert the mode to a line fbset understands. Then
I will force my SDL test app to use the mode previously set by fbset
and then I will run the savagedump to compare with the X dump.
I will try the procedure above ASAP and report back unless you have any
objections in the methodology.
Much simpler if you just load X first with UseBIOS False then dump the regs.
Do the same with UseBIOS True. You mentioned that X does not work if the
option UseBIOS is false.
Tony
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
Much simpler if you just load X first with UseBIOS False then dump the regs.
Do the same with UseBIOS True. You mentioned that X does not work if the
option UseBIOS is false.
Tony
That implies the kernel and the X driver are in sync yes?
Anyway I am attaching a little awk script that works a litle
better that diff for the untrained eye... along with the dumps
you asked. Maybe it makes some sense to you...
Here is the output
regdiff
$>./regdiff fb-640x480-64K@60 X-640x480-64K\@60-usebios\=false
Register: X working (Bios) X not working (UseBios=false)
-------------------------------------------------
SR1[0x0]: 50 00
SR1[0x1]: 7d 00
SR1[0x2]: ffffffc1 ffffffc7
SR1[0x3]: 28 7d
SR1[0x7]: ffffffc1 fffffffe
SR1[0xB]: ffffff82 12
SR5[0xB]: 7e 76
CR0[0x2]: 51 4f
CR0[0x3]: ffffff9d ffffff80
CR0[0xA]: 1f 00
CR0[0xB]: 1e 00
CR1[0x5]: ffffffe9 ffffffdf
CR1[0x6]: ffffffeb 0b
CR2[0x1]: 00 ffffffff
CR2[0x3]: 00 ffffffff
CR2[0x4]: 00 20
CR2[0x5]: 00 20
CR2[0x6]: 00 20
CR2[0x7]: 00 20
CR2[0x8]: 00 20
CR2[0x9]: 00 20
CR2[0xA]: 00 20
CR2[0xB]: 00 20
CR2[0xC]: 00 20
CR3[0x9]: ffffffbd ffffffb8
CR3[0xA]: 15 ffffff91
CR4[0x6]: 00 01
CR4[0x7]: ffffff8a 39
CR4[0x8]: ffffff89 38
CR4[0x9]: 61 ffffffe9
CR6[0x9]: 00 ffffff80
CR8[0x6]: 00 08
CR8[0x8]: 08 10
CR8[0x9]: 08 10
CR8[0xA]: 08 10
CR8[0xB]: 08 10
CR8[0xC]: 08 10
CR8[0xD]: 08 10
CR8[0xE]: 08 10
Much simpler if you just load X first with UseBIOS False then dump the regs.
Do the same with UseBIOS True. You mentioned that X does not work if the
option UseBIOS is false.
Tony
On 6/5/06, Vassilis Virvilis [off-list ref] wrote:
The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead. I tried for a while to add non-bios mode setting to crtc2
without much luck.
I don't care for dualhead right now. I can imagine it is 4 times weirder
than my current setup. What is crtc*?
For a short term fix, just program the registers with the new values
from the bios. You may be able to just get away with adjusting the
crtc1 dclk (SR12, SR13, SR29).
I will try that. Thanks for the suggestion.
A real fix may require special
calculations or tables for different chip/panel combos.
I will try for both of my monitors and I will report here any
success or failure unless of course I am told that this info is
not desirable.
Do you know if changing the number of colors 256/64K/16M requires
clock adjustments (SR12, SR13, SR29)?
Thanks for answering.
.bill
From: Alex Deucher <hidden> Date: 2006-06-07 21:32:27
On 6/5/06, Vassilis Virvilis [off-list ref] wrote:
Antonino A. Daplas wrote:
quoted
Much simpler if you just load X first with UseBIOS False then dump the regs.
Do the same with UseBIOS True. You mentioned that X does not work if the
option UseBIOS is false.
Tony
The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead. I tried for a while to add non-bios mode setting to crtc2
without much luck.
For a short term fix, just program the registers with the new values
from the bios. You may be able to just get away with adjusting the
crtc1 dclk (SR12, SR13, SR29). A real fix may require special
calculations or tables for different chip/panel combos.
Alex
From: Alex Deucher <hidden> Date: 2006-06-08 01:45:57
On 6/6/06, Vassilis Virvilis [off-list ref] wrote:
Alex Deucher wrote:
quoted
On 6/5/06, Vassilis Virvilis [off-list ref] wrote:
The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead. I tried for a while to add non-bios mode setting to crtc2
without much luck.
I don't care for dualhead right now. I can imagine it is 4 times weirder
than my current setup. What is crtc*?
twisters/prosavages can't do dualhead anyway. crtc stands for crt
controller. it's just another name for a display controller (ie,
thing that scans out the image).
quoted
For a short term fix, just program the registers with the new values
from the bios. You may be able to just get away with adjusting the
crtc1 dclk (SR12, SR13, SR29).
I will try that. Thanks for the suggestion.
A real fix may require special
quoted
calculations or tables for different chip/panel combos.
I will try for both of my monitors and I will report here any
success or failure unless of course I am told that this info is
not desirable.
Sounds good.
Do you know if changing the number of colors 256/64K/16M requires
clock adjustments (SR12, SR13, SR29)?
Hi Alex,
I would like to thank you and Antonino for all the help so far. I have finally
manage to make my twister to sync with both of my screens (one TFT, one CRT).
I am attaching the patch. The patch itself disables all modes other than
640x480@64K-60Hz. Note that the patch is clearly inapropriate but it
may sparkle some discussion about how this thing works.
One more question:
Alex Deucher wrote:
quoted
quoted
The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead. I tried for a while to add non-bios mode setting to crtc2
without much luck.
When you say panel what do you mean?
a) The rest of the framebuffer and scan logic resided in CRTC?
b) The screen attached to CRTC?
I believe a) but I would like to know for sure.
Thanks again...
.bill
That is because it wasn't a brilliant question and when I say screen
I mean monitor. Sorry for the confusion. I was trying to figure out
if the thing was external to the PCI card (i.e. in the monitor) or internal
(i.e. DAC). But since I am not familiar with the domain I don't know
how to ask the questions properly.
Anyway is there a way to probe for that FP thing? or to distinguish
between them?
Perhaps if we had a few more testers we
could figure out a pattern for common panels and put in some sort of
generic fix.
I don't mind produce more data or test things as long as I have the
equipment...
.bill
The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead. I tried for a while to add non-bios mode setting to crtc2
without much luck.
When you say panel what do you mean?
a) The rest of the framebuffer and scan logic resided in CRTC?
b) The screen attached to CRTC?
I believe a) but I would like to know for sure.
panel = LCD panel (in contrast to CRT = Cathode Ray Tube)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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: Alex Deucher <hidden> Date: 2006-06-12 14:37:54
On 6/12/06, Vassilis Virvilis [off-list ref] wrote:
Alex Deucher wrote:
quoted
I'm not sure I understand your question.
That is because it wasn't a brilliant question and when I say screen
I mean monitor. Sorry for the confusion. I was trying to figure out
if the thing was external to the PCI card (i.e. in the monitor) or internal
(i.e. DAC). But since I am not familiar with the domain I don't know
how to ask the questions properly.
Anyway is there a way to probe for that FP thing? or to distinguish
between them?
about they most you can get on the savage is detecting whether or not
there is a panel attached and what size the panel is. AFAIK, there's
no way to detect the panel specifics. However, if we got some more
datapoints and found that most panels need the plls tweaked to a
certain range we could probably handle it more gracefully. You could
probably even get it working now if you used a special modeline.
Alex
quoted
Perhaps if we had a few more testers we
could figure out a pattern for common panels and put in some sort of
generic fix.
I don't mind produce more data or test things as long as I have the
equipment...
.bill
about they most you can get on the savage is detecting whether or not
there is a panel attached and what size the panel is. AFAIK, there's
no way to detect the panel specifics. However, if we got some more
datapoints and found that most panels need the plls tweaked to a
certain range we could probably handle it more gracefully. You could
probably even get it working now if you used a special modeline.
Alex
That's true. See at the start of the thread...
http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=114781832315079&w=2
"""
>As a workaround for my EIZO I tried (succesfully)
>#This syncronize at 60Hz vertical refresh rate (fbset -i repors 160Hz)
>fbset -xres 640 -yres 480 -depth 16 -t 15385 48 16 33 10 96 2
This is not working for my other monitor a TFT Medion (1280x1024). So
I guess that makes it an EDID dependent bug.
"""
From: Alex Deucher <hidden> Date: 2006-06-12 17:39:57
On 6/11/06, Vassilis Virvilis [off-list ref] wrote:
Hi Alex,
I would like to thank you and Antonino for all the help so far. I have finally
manage to make my twister to sync with both of my screens (one TFT, one CRT).
I am attaching the patch. The patch itself disables all modes other than
640x480@64K-60Hz. Note that the patch is clearly inapropriate but it
may sparkle some discussion about how this thing works.
One more question:
Alex Deucher wrote:
quoted
quoted
quoted
The reason the savage xorg drver uses the bios is because almost every
panel they connect to the chip seems to require fairly custom timings.
the twisters and prosavages are even worse than the discrete chips.
Also, only the bios seems to know the magic incantation necessary for
dualhead. I tried for a while to add non-bios mode setting to crtc2
without much luck.
When you say panel what do you mean?
a) The rest of the framebuffer and scan logic resided in CRTC?
b) The screen attached to CRTC?
I believe a) but I would like to know for sure.
I'm not sure I understand your question. The panel connects to the
chip via a built in flat panel interface, however it has to be driven
with timings and a clock just like a CRT. The CRTC can drive either
the FP interface or the DAC or both. Based on you patch it seems you
only need to tweak the clock. Perhaps if we had a few more testers we
could figure out a pattern for common panels and put in some sort of
generic fix.
Alex