|
Description
ptouchman
2018-05-03 21:32:06 UTC
P Touchman, thank you for moving the matter here. Looking at the log, it appears that OpenChrome DDX was able to detect the presence of a VGA cable and polled the I2C bus address, but was not able to obtain EDID (Extended Display ID) from the monitor. Can you try this with another VGA cable? If this is not possible, can you clean the cable contacts? It is always possible that the cable might have a bent pin as well. If that does not work, you may want to try a different monitor. (In reply to ptouchman from comment #0) > Created attachment 139327 [details] > xorg log > > I've got a VE900 Via board with integrated VIA Chrome graphics. > > https://www.viatech.com/en/support/eol/ve-900-eol/ > > > I'm trying to use it with Debian 9.3 32 bit and upon boot, I just get a > blank screen with VGA. My LCD monitor says "out of range". > > I've tried boot parameters like video=800x600@60 but it doesn't make a > difference. > > CTRL+ALT+F1 will bring me back to text mode and CTRL+ALT+F7 will go back to > the blank screen. > > > This is with debian's > https://packages.debian.org/stretch/x11/xserver-xorg-video-openchrome and > freshly compiled git Openchrome and it didn't make a difference. > > > Any ideas? Sure I'll try another monitor, I've actually got it hooked up through a KVM switchbox so perhaps it's not able to get the DDC through. I'll try it direct connection to the VGA and see how that fares. I did however also hook it up with a direct HDMI connection as the VE900 has both VGA and HDMI ports with the same blank screen results. The HDMI port was able to switch between text and graphic mode with CTRL+ALT+F1 and CTRL+ALT+F7. Okay, please do not attach anything other than what is really necessary if you want the developer to help you figure out why your display is not working. You should have disclosed that you were using a KVM switch since I have no control over the equipment you have. I got burned 2 years ago when someone I was helping out was using a faulty SD Card to PATA reader even though the code was already fixed. https://bugs.freedesktop.org/show_bug.cgi?id=91966#c329 Again, there is currently no support for VX900 chipset's integrated TMDS transmitter that handles HDMI. If the HDMI display is displaying anything this is because VGA BIOS set the registers up, but OpenChrome DDX currently does not have the code to control them. (In reply to ptouchman from comment #3) > Sure I'll try another monitor, I've actually got it hooked up through a KVM > switchbox so perhaps it's not able to get the DDC through. > > I'll try it direct connection to the VGA and see how that fares. > > I did however also hook it up with a direct HDMI connection as the VE900 has > both VGA and HDMI ports with the same blank screen results. > > The HDMI port was able to switch between text and graphic mode with > CTRL+ALT+F1 and CTRL+ALT+F7. Created attachment 139360 [details]
dell ultrascanp991 xorg log - display is still blank
Ok I don't think it's the DDC, because I tried an old Dell Ultrascan P991 CRT monitor and got the same blank results.
One thing I did notice with the old CRT was a brief flash of color which looked like what should be displaying but super skewed. It must be displaying at a frequency that the monitor can't handle and it put up a message saying "out of range" just like my LCD monitor did.
I thought I'd try to use the via_reg_tool to see what it said:
"sudo ./via_reg_tool -m" while the console text is active said:
via-chrome-tool (C) 2009 by VIA Technologies, Inc.
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
SL in System memory: 0x10000000, RTSF in SL: 0x0
Primary Display:
H total=800, active=640, blank (640-544), sync(656-240)
V total=525, active=480, blank (480-13), sync(489-11)
base_addr=0x00003250, bpp=8
Secondary Display:
H total=246, active=246, blank (1534-7928), sync(4085-509)
V total=1534, active=1982, blank (2038-2038), sync(2045-23)
base_addr=0x00000000, bpp=8
Panel Scaling enabled, mode Interpolation
Scaling Factors: horizontal=0, vertical=1707
LVDS Seq Mode: LVDS1 + LVDS2
LVDS CRT Mode: LVDS1 + LVDS2
LVDS Channel 1 Format OpenLDI, Power Down
LVDS Channel 2 Format OpenLDI, Power Down
and if I wanted to see what the graphics mode would be I tried:
"sleep 5; sudo ./via_reg_tool -m" and then hit CTRL+ALT+F7 to get into the graphics mode:
via-chrome-tool (C) 2009 by VIA Technologies, Inc.
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
SL in System memory: 0x10000000, RTSF in SL: 0x0
Primary Display:
H total=1376, active=1024, blank (1032-96), sync(1072-136)
V total=808, active=768, blank (769-40), sync(769-3)
base_addr=0x04000000, bpp=32
Secondary Display:
H total=246, active=246, blank (1534-7928), sync(4085-509)
V total=1534, active=1982, blank (2038-2038), sync(2045-23)
base_addr=0x00000000, bpp=8
Panel Scaling enabled, mode Interpolation
Scaling Factors: horizontal=0, vertical=1707
LVDS Seq Mode: LVDS1 + LVDS2
LVDS CRT Mode: LVDS1 + LVDS2
LVDS Channel 1 Format OpenLDI, Power Down
LVDS Channel 2 Format OpenLDI, Power Down
I also tried the -p option while I was in console mode (I forgot to try it in graphics mode with a sleep command).
via-chrome-tool (C) 2009 by VIA Technologies, Inc.
This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
VCK PLL: dm=653, dtx=2, dr=2, dn=2 VCK Fvco=2344572 kHz, Fout=586143 kHz
ECK PLL: dm=596, dtx=2, dr=0, dn=1 ECK Fvco=2854054 kHz, Fout=0 kHz
LDCK PLL: dm=596, dtx=2, dr=2, dn=1 LDCK Fvco=2854054 kHz, Fout=713513 kHz
ptouchman, the flash thing is likely due to analog VGA sensing for connector detection. Post the Xorg.0.log again to see if EDID is being transmitted properly to VX900 chipset. (In reply to ptouchman from comment #6) > Ok I don't think it's the DDC, because I tried an old Dell Ultrascan P991 > CRT monitor and got the same blank results. > > One thing I did notice with the old CRT was a brief flash of color which > looked like what should be displaying but super skewed. It must be > displaying at a frequency that the monitor can't handle and it put up a > message saying "out of range" just like my LCD monitor did. > > > I thought I'd try to use the via_reg_tool to see what it said: > > "sudo ./via_reg_tool -m" while the console text is active said: > > via-chrome-tool (C) 2009 by VIA Technologies, Inc. > This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY > > SL in System memory: 0x10000000, RTSF in SL: 0x0 > Primary Display: > H total=800, active=640, blank (640-544), sync(656-240) > V total=525, active=480, blank (480-13), sync(489-11) > base_addr=0x00003250, bpp=8 > > Secondary Display: > H total=246, active=246, blank (1534-7928), sync(4085-509) > V total=1534, active=1982, blank (2038-2038), sync(2045-23) > base_addr=0x00000000, bpp=8 > > Panel Scaling enabled, mode Interpolation > Scaling Factors: horizontal=0, vertical=1707 > > LVDS Seq Mode: LVDS1 + LVDS2 > LVDS CRT Mode: LVDS1 + LVDS2 > LVDS Channel 1 Format OpenLDI, Power Down > LVDS Channel 2 Format OpenLDI, Power Down > > > > and if I wanted to see what the graphics mode would be I tried: > > "sleep 5; sudo ./via_reg_tool -m" and then hit CTRL+ALT+F7 to get into the > graphics mode: > > via-chrome-tool (C) 2009 by VIA Technologies, Inc. > This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY > > SL in System memory: 0x10000000, RTSF in SL: 0x0 > Primary Display: > H total=1376, active=1024, blank (1032-96), sync(1072-136) > V total=808, active=768, blank (769-40), sync(769-3) > base_addr=0x04000000, bpp=32 > > Secondary Display: > H total=246, active=246, blank (1534-7928), sync(4085-509) > V total=1534, active=1982, blank (2038-2038), sync(2045-23) > base_addr=0x00000000, bpp=8 > > Panel Scaling enabled, mode Interpolation > Scaling Factors: horizontal=0, vertical=1707 > > LVDS Seq Mode: LVDS1 + LVDS2 > LVDS CRT Mode: LVDS1 + LVDS2 > LVDS Channel 1 Format OpenLDI, Power Down > LVDS Channel 2 Format OpenLDI, Power Down > > > I also tried the -p option while I was in console mode (I forgot to try it > in graphics mode with a sleep command). > > > via-chrome-tool (C) 2009 by VIA Technologies, Inc. > This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY > > VCK PLL: dm=653, dtx=2, dr=2, dn=2 VCK Fvco=2344572 kHz, Fout=586143 kHz > ECK PLL: dm=596, dtx=2, dr=0, dn=1 ECK Fvco=2854054 kHz, Fout=0 kHz > LDCK PLL: dm=596, dtx=2, dr=2, dn=1 LDCK Fvco=2854054 kHz, Fout=713513 kHz ptouchman, I now see the Xorg.0.log. It appears that EDID is coming in from the Dell monitor. It is supposedly selecting 1024 x 768 At this point, I am not sure why the graphics is not working. If you still have an old configuration files like xorg.conf, remove it since OpenChrome DDX can automatically handle mode setting. Since the Dell monitor in question can handle 1600 x 1200, why is it selecting much lower screen resolution like 1024 x 768? Another thing to consider is testing the hardware on Ubuntu based distribution like Xubuntu or Lubuntu. Outside of Xubuntu / Lubuntu, I have only tried Debian 8 (VIA EPIA-M; CLE266 chipset) and FreeBSD 11 64-bit (ABIT IP-95; P4M890 chipset) so far. Revisit Debian 9 after making sure the hardware works on Xubuntu / Lubuntu. I have already upgraded several of my boxes to Xubuntu / Lubuntu 18.04 and it is working fine (about the same stability as Xubuntu / Lubuntu 16.04). (In reply to Kevin Brace from comment #9) > If you still have an old configuration files like xorg.conf, remove it since > OpenChrome DDX can automatically handle mode setting. > Since the Dell monitor in question can handle 1600 x 1200, why is it > selecting much lower screen resolution like 1024 x 768? I thought the same thing, maybe the Dell's preferred res is 1024x768? from https://en.wikipedia.org/wiki/Extended_Display_Identification_Data Preferred timing mode specified in descriptor block 1. For EDID 1.3+ the preferred timing mode is always in the first Detailed Timing Descriptor. In that case, this bit specifies whether the preferred timing mode includes native pixel format and refresh rate. And in the Xorg.0.log it says: [ 18.814] (II) CHROME(0): Printing probed modes for output VGA-1 [ 18.814] (II) CHROME(0): Modeline "1024x768"x85.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz eP) [ 18.814] (II) CHROME(0): Modeline "1600x1200"x85.0 229.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (106.2 kHz e) So it's probably picking up that first 1024x768 @ 85hz resolution. One thing I did notice in the log was: [ 19.017] DRM memory allocation failed -6 [ 19.017] via_xv.c : viaInitVideo, Screen[0] I don't know if that is significant or not. Created attachment 139366 [details]
Asus VS248 xorg log
This is what it gets for DDC from an Asus VS248 (1920x1080@60)
One thing that I noticed was that it initially reports:
[ 20.888] (II) CHROME(0): Printing probed modes for output VGA-1
[ 20.888] (II) CHROME(0): Modeline "1920x1080"x60.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[ 20.888] (II) CHROME(0): Modeline "1920x1080"x60.0 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
[ 20.888] (II) CHROME(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
and then later on it will print x0.0.
(snipped a few lines from the output)
[ 109.951] (II) CHROME(0): Printing DDC gathered Modelines:
[ 109.951] (II) CHROME(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[ 109.952] (II) CHROME(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
[ 109.952] (II) CHROME(0): Modeline "1920x1080"x60.0 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
What's wacky to me is that I can get a perfectly visible display out of grub at boot time at 1024x768 on the Dell. I wonder if it would be possible to dump the registers when it's displaying a VESA mode. I would be happy to send you this board if that would be easier to figure out. You can keep it if you like and add it to your stable of test hardware. I've got plenty of other hardware. I just wanted to see how this little board would run mame under linux. Is the display working with this ASUS full HD monitor? It appears that the display is working in this case. (In reply to ptouchman from comment #12) > Created attachment 139366 [details] > Asus VS248 xorg log > > This is what it gets for DDC from an Asus VS248 (1920x1080@60) > > One thing that I noticed was that it initially reports: > > [ 20.888] (II) CHROME(0): Printing probed modes for output VGA-1 > [ 20.888] (II) CHROME(0): Modeline "1920x1080"x60.0 148.50 1920 2008 > 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) > [ 20.888] (II) CHROME(0): Modeline "1920x1080"x60.0 172.80 1920 2040 > 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) > [ 20.888] (II) CHROME(0): Modeline "1600x1200"x60.0 162.00 1600 1664 > 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) > > and then later on it will print x0.0. > > (snipped a few lines from the output) > > [ 109.951] (II) CHROME(0): Printing DDC gathered Modelines: > [ 109.951] (II) CHROME(0): Modeline "1920x1080"x0.0 148.50 1920 2008 > 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) > [ 109.952] (II) CHROME(0): Modeline "1600x1200"x0.0 162.00 1600 1664 > 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) > [ 109.952] (II) CHROME(0): Modeline "1920x1080"x60.0 172.80 1920 2040 > 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) P Touchman, is there a configuration file somewhere? [ 290.063] (II) CHROME(0): Using hsync ranges from config file [ 290.063] (II) CHROME(0): Using vrefresh ranges from config file That weird x0.0 might be coming from there. More on this configuration file (xorg.conf). https://wiki.debian.org/Xorg (In reply to ptouchman from comment #12) > Created attachment 139366 [details] > Asus VS248 xorg log > > This is what it gets for DDC from an Asus VS248 (1920x1080@60) > > One thing that I noticed was that it initially reports: > > [ 20.888] (II) CHROME(0): Printing probed modes for output VGA-1 > [ 20.888] (II) CHROME(0): Modeline "1920x1080"x60.0 148.50 1920 2008 > 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) > [ 20.888] (II) CHROME(0): Modeline "1920x1080"x60.0 172.80 1920 2040 > 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) > [ 20.888] (II) CHROME(0): Modeline "1600x1200"x60.0 162.00 1600 1664 > 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) > > and then later on it will print x0.0. > > (snipped a few lines from the output) > > [ 109.951] (II) CHROME(0): Printing DDC gathered Modelines: > [ 109.951] (II) CHROME(0): Modeline "1920x1080"x0.0 148.50 1920 2008 > 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) > [ 109.952] (II) CHROME(0): Modeline "1600x1200"x0.0 162.00 1600 1664 > 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) > [ 109.952] (II) CHROME(0): Modeline "1920x1080"x60.0 172.80 1920 2040 > 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) More on xorg.conf. https://manpages.debian.org/stretch/xserver-xorg-core/xorg.conf.d.5.en.html (In reply to ptouchman from comment #11) > . . . > > One thing I did notice in the log was: > > [ 19.017] DRM memory allocation failed -6 > [ 19.017] via_xv.c : viaInitVideo, Screen[0] > > I don't know if that is significant or not. That stuff is not important. For many VIA Chrome IGPs, DDX is running without DRM. For earlier generation devices, VIA DRM supports them, but Linux kernel developers have effectively discontinued DRI1 support (now hidden behind a compile switch.), so even the earlier generation devices will need to run without VIA DRM. (In reply to Kevin Brace from comment #14) > Is the display working with this ASUS full HD monitor? > It appears that the display is working in this case. > > Unfortunately the Asus VS248 says "out of range". Created attachment 139378 [details]
Knoppix8.1 works Xorg.0.log
To my surprise, booting Knoppix 8.1 installed to a flash drive worked! Here's the Xorg.0.log file.
Created attachment 139379 [details]
via reg dump from working knoppix 8.1
Running via reg dump on a working Knoppix 8.1 1024x768@85 desktop screen.
Created attachment 139380 [details]
via reg dump from non working debian 9.3 1024x768
running sleep 5;sudo via_reg_dump -d >> reg_dump_file.txt and switching to the screen with CTRL+ALT+F7
Thanks for your suggestion to try another OS, I booted Knoppix 8.1 live DVD installed to a flash drive and it worked!!! I couldn't believe it. Especially as it's supposed to be based on Debian 9.3. So go figure. I also looked very hard for an xorg.conf file in Debian 9.3 and there wasn't any in /etc/X11 or in /usr/share/X11/. Since the knoppix 8.1 was working I thought I'd see what the performance of mame was and I only got 30fps on pacman (full speed would be 60fps). Created attachment 139383 [details]
via_reg_dump_differences_not_working_compare_to_working.txt
Created attachment 139384 [details]
Xorg.0.log diff between debian93 (not working) and knoppix81 (working)
using sed to strip off the first 13 characters of each Xorg.0.log and then running diff
sed 's/.\{13\}\(.*$\)/\1/'
P Touchman, I just wanted to "prove" that at least one version of the OpenChrome DDX release works with your hardware. Now that we know OpenChrome DDX Version 0.6 works with VIA VE-900 mainboard, you may want to try the OpenChrome DDX latest upstream code with Knoppix 8.1. If I understand it correctly, Knoppix writes system log files to a RAM disk, then writes them back when you shutdown. Anyway, my motivation for spending a lot time troubleshooting OpenChrome DDX functionality with you is to do some preliminary RC (Release Candidate) testing done prior to releasing an RC version. There are still about 4 to 5 more issues I need to take care of before an RC version can be released. (In reply to ptouchman from comment #22) > Thanks for your suggestion to try another OS, I booted Knoppix 8.1 live DVD > installed to a flash drive and it worked!!! I couldn't believe it. > Especially as it's supposed to be based on Debian 9.3. So go figure. > > > I also looked very hard for an xorg.conf file in Debian 9.3 and there wasn't > any in /etc/X11 or in /usr/share/X11/. > > > Since the knoppix 8.1 was working I thought I'd see what the performance of > mame was and I only got 30fps on pacman (full speed would be 60fps). I have not put in any effort into writing the rendering portion of the code for the past 3 years since the initialization / mode setting / standby resume portions of the code had too many issues that I needed to take care of those portions first. Besides that, so much of my time resources went into fixing OpenChrome DRM as well. I would imagine that writing OpenChrome DRM will likely take up almost all of my development time resources for the rest of the year. (In reply to ptouchman from comment #22) > > Since the knoppix 8.1 was working I thought I'd see what the performance of > mame was and I only got 30fps on pacman (full speed would be 60fps). (In reply to Kevin Brace from comment #26) > I have not put in any effort into writing the rendering portion of the code > for the past 3 years since the initialization / mode setting / standby > resume portions of the code had too many issues that I needed to take care > of those portions first. > Besides that, so much of my time resources went into fixing OpenChrome DRM > as well. > I would imagine that writing OpenChrome DRM will likely take up almost all > of my development time resources for the rest of the year. > > > (In reply to ptouchman from comment #22) > > > > Since the knoppix 8.1 was working I thought I'd see what the performance of > > mame was and I only got 30fps on pacman (full speed would be 60fps). I'm glad that I got it to finally work! Maybe I'll have mame frameskip a little, I suppose it doesn't have to render every frame. 30 fps is actually playable. After reading your presentation I can see that it's a pretty monumental task to write video drivers. (A very interesting read, BTW) https://www.x.org/wiki/Events/XDC2017/brace_openchrome.pdf P Touchman, a lot of my time got taken for various time consuming tasks this week (the week of May 6th, 2018).
For example, I had to replace my main development computer's (HP 2133 mini-note) SSD which just died after one year of use.
In practice, some other bad things happened as well (non-OpenChrome related), but they are personal, so I will not discuss them here.
I will have limited time to work on OpenChrome for the week of May 13th, 2018, but I will still like to make some progress.
If you can, you may want to test the latest OpenChrome DDX with Knoppix.
If it is a lot more unstable, it might be because of the new connector detection code not working well sometimes.
To test against this, you will like to boot the computer several times to see if the VGA input correctly displays something.
If you think the non-detection of the display is sporadic, then I can create a patch disabling this feature.
Just for disclosure, I am aware of this connector detection code not working very well with some chipsets.
I am considering removing them for the upcoming OpenChrome DDX Version 0.7 if I cannot ensure that it works well with all the chipsets.
(In reply to ptouchman from comment #27)
>
> I'm glad that I got it to finally work! Maybe I'll have mame frameskip a
> little, I suppose it doesn't have to render every frame. 30 fps is actually
> playable.
>
>
> After reading your presentation I can see that it's a pretty monumental task
> to write video drivers. (A very interesting read, BTW)
>
> https://www.x.org/wiki/Events/XDC2017/brace_openchrome.pdf
P Touchman, thus far, I have not touched any of the rendering related code other than remove compilation warnings (mainly of "unused variables" type warnings). In general, the rendering performance of OpenChrome DDX has been going downward since X Server 1.11 (Lubuntu 12.04) even with the same exact OpenChrome DDX code. I know this because I do test the same code by compiling against X Server 1.11 and 1.19, and 1.19 is clearly slower. It is possible this is Linux kernel related since I didn't use identical kernel. I do not plan to work on rendering related code until OpenChrome DRM is mainlined (accepted) into the Linux kernel tree. (In reply to ptouchman from comment #22) > Thanks for your suggestion to try another OS, I booted Knoppix 8.1 live DVD > installed to a flash drive and it worked!!! I couldn't believe it. > Especially as it's supposed to be based on Debian 9.3. So go figure. > > > I also looked very hard for an xorg.conf file in Debian 9.3 and there wasn't > any in /etc/X11 or in /usr/share/X11/. > > > Since the knoppix 8.1 was working I thought I'd see what the performance of > mame was and I only got 30fps on pacman (full speed would be 60fps). P Touchman, I did not write most of OpenChrome DDX or DRM code.
All I have focused on are display automatic detection and improving standby resume behavior for both DDX and DRM.
Although it might seem less than perfect, I am particularly focused on improving the usability and reliability of OpenChrome.
That being said, the latest version you used was a developmental version (i.e., Version 0.6.174), so it might contain issues.
Typically, I do try to focus on fixes prior to the formal release version (i.e., Version 0.6) so that it is as stable as possible.
Despite my best efforts, unfortunately things do break like OpenChrome DDX Version 0.5 breaking HP 2133 mini-note's WLAN (Version 0.6 fixed this bug.).
If I were to comment on graphics device driver development, it is pretty hard to attract developers to do this for non-Big 3 x86 platform graphics devices (Intel, AMD, and NVIDIA).
Nowadays, I think almost all Linux graphics device driver developers are employed (paid) developers.
This is why very little development activities happen outside of Big 3 x86 platform graphics devices.
Besides that, it is really difficult to get people to develop code for graphics devices older than 5 years (This is my observation.), in general.
I was not too surprised that I got to present at XDC2017, although I was pretty much the only unpaid developer at the conference (some of the Nouveau developers work for RedHat).
(In reply to ptouchman from comment #27)
>
> After reading your presentation I can see that it's a pretty monumental task
> to write video drivers. (A very interesting read, BTW)
>
> https://www.x.org/wiki/Events/XDC2017/brace_openchrome.pdf
(In reply to Kevin Brace from comment #28) > P Touchman, a lot of my time got taken for various time consuming tasks this > week (the week of May 6th, 2018). > For example, I had to replace my main development computer's (HP 2133 > mini-note) SSD which just died after one year of use. > In practice, some other bad things happened as well (non-OpenChrome > related), but they are personal, so I will not discuss them here. > I will have limited time to work on OpenChrome for the week of May 13th, > 2018, but I will still like to make some progress. > If you can, you may want to test the latest OpenChrome DDX with Knoppix. > If it is a lot more unstable, it might be because of the new connector > detection code not working well sometimes. > To test against this, you will like to boot the computer several times to > see if the VGA input correctly displays something. > If you think the non-detection of the display is sporadic, then I can create > a patch disabling this feature. > Just for disclosure, I am aware of this connector detection code not > working very well with some chipsets. > I am considering removing them for the upcoming OpenChrome DDX Version 0.7 > if I cannot ensure that it works well with all the chipsets. > > Hi Kevin, I'll give it a spin when I get a chance. I was thinking that if the knoppix 0.6 works maybe I could figure out which version "breaks" it by compiling some versions in between 0.6.0 and 0.6.175 with git bisect. (In reply to Kevin Brace from comment #30) > This is why very little development activities happen outside of Big 3 x86 > platform graphics devices. > Besides that, it is really difficult to get people to develop code for > graphics devices older than 5 years (This is my observation.), in general. > I was not too surprised that I got to present at XDC2017, although I was > pretty much the only unpaid developer at the conference (some of the Nouveau > developers work for RedHat). Nobody loves old hardware...*sniff* except us 8-) It breaks my heart to see all of this great hardware get thrown away in favor of the shiny new thing. I tend to belong to the camp that thinks that computers made in the past 6 to 7 years are adequate for everyday mundane tasks like browsing the Internet, and there is no need to replace them until they break. Unlike 10+ years ago, computers are not really getting faster every year. Performance improvements have slowed down in the past 5 years, and this means the user does not have to replace the computers too often. In the case of VIA, they never worked with the FOSS community closely to integrate their code into Linux kernel and Mesa. As a result, I think they inconvenienced their users a lot. All I am trying to do is to make the end user experience better than where it used to be a few years ago. Eventually, I will get around to adding various acceleration features to improve the user experience down the road. (In reply to ptouchman from comment #32) > > Nobody loves old hardware...*sniff* except us 8-) > > It breaks my heart to see all of this great hardware get thrown away in > favor of the shiny new thing. I think you can start from Version 0.6.116 for bisecting. The next commit adds the connector detection functionality to VGA. Perhaps this is causing the display detection issues. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/log/?ofs=250 (In reply to ptouchman from comment #31) > > Hi Kevin, > > I'll give it a spin when I get a chance. I was thinking that if the knoppix > 0.6 works maybe I could figure out which version "breaks" it by compiling > some versions in between 0.6.0 and 0.6.175 with git bisect. Created attachment 139585 [details]
Xorg.0.log compiled 0.6 on debian 9.3 got out of range
I checked out the openchrome-0.6 tag and compiled it, copied the openchrome.la and openchrome.so to /usr/lib/xorg/modules/drivers directory and it didn't work. I got the "out of range" message on my Dell P991. This was under Debian 9.3.
I was thinking that version 0.6 would work since that was the version that worked under knoppix8.1.
Maybe I'll try copying the xorg conf file from knoppix8.1 over to debian 9.3 and see if that makes a difference.
from the working knoppix8.1: sudo ./via_regs_dump -p via-chrome-tool (C) 2009 by VIA Technologies, Inc. This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY VCK PLL: dm=591, dtx=2, dr=1, dn=1 VCK Fvco=2830191 kHz, Fout=1415095 kHz ECK PLL: dm=596, dtx=2, dr=0, dn=1 ECK Fvco=2854054 kHz, Fout=0 kHz LDCK PLL: dm=596, dtx=2, dr=2, dn=1 LDCK Fvco=2854054 kHz, Fout=713513 kHz and from my compiled 0.6 on debian 9.3 it looks the same: via-chrome-tool (C) 2009 by VIA Technologies, Inc. This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY VCK PLL: dm=591, dtx=2, dr=1, dn=1 VCK Fvco=2830191 kHz, Fout=1415095 kHz ECK PLL: dm=596, dtx=2, dr=0, dn=1 ECK Fvco=2854054 kHz, Fout=0 kHz LDCK PLL: dm=596, dtx=2, dr=2, dn=1 LDCK Fvco=2854054 kHz, Fout=713513 kHz The frequencies look identical. I switch to a text mode with CTRL+ALT+F1 then this command chvt 7; sleep 2; sudo ./via_regs_dump -p; chvt 1 (I can't remember if I have to sudo chvt or just chvt) I am convinced that my debian 9.3 installation is cursed. I compiled openchrome 0.6 and it didn't work. I even copied the openchrome driver to my debian 9.3 from the working knoppix 8.1 and it didn't work properly either (same out of range error). After checking the debian website, there's a newer debian 9.4 that was released in March that I'm going to give a try. There's also a fresh knoppix 8.2 that was released a few days ago that I'll give a try as well. I am back and I will have more time to spend on OpenChrome related issues for the next few weeks. Comparing my Xorg.0.log and your Debian 9.3 Xorg.0.log, it appears that there is still a hidden xorg.conf type file that is specifying the monitor frequency range. For example, I do not have the following lines in my Xorg.0.log. > (II) CHROME(0): Using EDID range info for horizontal sync > (II) CHROME(0): Using EDID range info for vertical refresh If you have another spare hard drive or SSD, go ahead and install a fresh Debian 9.3 or 9.4 and see what happens. (In reply to ptouchman from comment #37) > I am convinced that my debian 9.3 installation is cursed. I compiled > openchrome 0.6 and it didn't work. I even copied the openchrome driver to > my debian 9.3 from the working knoppix 8.1 and it didn't work properly > either (same out of range error). > > After checking the debian website, there's a newer debian 9.4 that was > released in March that I'm going to give a try. > > There's also a fresh knoppix 8.2 that was released a few days ago that I'll > give a try as well. P Touchman, some new development. I recently got VIA Technologies VT1632(A) DVI transmitter code into the OpenChrome DRM, so I will have more time to spend on analyzing other issues. I do not wish to go into too many details, but I own another copy of ECS VX900-I mainboard. However, this one is connected to Philips 720p HDTV. Anyway, I installed Xubuntu 18.04 32-bit and 64-bit into this computer for OpenChrome DRM development purposes. I already got OpenChrome DRM compiled for the 64-bit installation, but not for 32-bit installation yet. I am compiling OpenChrome DRM for the 32-bit installation in the background right now as I write this e-mail on the 32-bit installation. I have been trying to figure out weird issues that affect VGA on OpenChrome DRM when HDMI and VGA are both connected. Currently, VGA screen gets totally distorted when HDMI is connected, but I have not figured out why this happens (spent about 2 hours on this issue yesterday, but haven't found the reason why this happens). That activity happened on the 64-bit installation again with OpenChrome DRM running. Now, I decided to boot the 32-bit installation, and noticed the same exact problem that plagued you. Even though OpenChrome DDX does not support VX900 chipset's integrated DVI / HDMI transmitter at this point (this will happen in the future), if one boots the computer with both VGA and HDMI connected, one will get the "Out of Range" warning from the monitor connected to VGA. I was able to workaround the issue for now by temporarily disconnecting HDMI from the ECS VX900-I mainboard, but keeping the VGA connected. Try that workaround to see if it also works with you. I will likely need to put in some code to not let this situation happen even if HDMI is not going to be supported on OpenChrome DDX for now. Hi Kevin, Sorry to not reply for a couple of weeks, I haven't had time to fiddle with the VX900. I got a new power supply and it emits a lot of chemical odors so every time I work with it it feels like its poisoning me. That's discouraging me from working with it lately so I've only been firing up the VX900 for very short periods. I did get an interesting bit of kit the other day, an NEC Theatersync video processor that will tell me what the frequency is of the vga input signal even if it can't display it. I was thinking that that would tell me what the frequency is of the "out of range" video. If you feed it a signal that it doesn't like it gives you a blue screen but the OSD menus and information still work. So the Theatersync can take in VGA up to 1366x768 and rescale it to output VGA and HDMI. The NEC Theatersync gives out its own EDID and both Knoppix 8.1 and 8.2 will go to x just fine on the VX900. But I've got a wacky Sansui SLED2900 29 inch tv that gives out no EDID at all on its VGA port and the VX900 thinks that it's got no connection, and the old "out of range" message. I was thinking that maybe I could force-feed the driver an EDID file with a kernel boot parameter if that would help. from https://wiki.archlinux.org/index.php/kernel_mode_setting drm_kms_helper.edid_firmware=edid/your_edid.bin drm.edid_firmware=edid/your_edid.bin Resolution Name 800x600 edid/800x600.bin 1024x768 edid/1024x768.bin 1280x1024 edid/1280x1024.bin 1600x1200 edid/1600x1200.bin 1680x1050 edid/1680x1050.bin 1920x1080 edid/1920x1080.bin P Touchman, I am taking a break from OpenChrome development for several weeks to work on a different graphics stack (r128), but I am still willing to do some troubleshooting sometimes. I think the problem is with OpenChrome DDX in this situation as explained with Comment 39 since I was able to reproduce the problem. I do not think feeding those EDID parameters really matter since they are KMS related, and the OpenChrome DDX you are dealing with does not currently handle KMS since OpenChrome DRM is still mainlined. (In reply to ptouchman from comment #40) > Hi Kevin, > > Sorry to not reply for a couple of weeks, I haven't had time to fiddle with > the VX900. I got a new power supply and it emits a lot of chemical odors so > every time I work with it it feels like its poisoning me. That's > discouraging me from working with it lately so I've only been firing up the > VX900 for very short periods. > > > > > > I did get an interesting bit of kit the other day, an NEC Theatersync video > processor that will tell me what the frequency is of the vga input signal > even if it can't display it. I was thinking that that would tell me what > the frequency is of the "out of range" video. If you feed it a signal that > it doesn't like it gives you a blue screen but the OSD menus and information > still work. > > So the Theatersync can take in VGA up to 1366x768 and rescale it to output > VGA and HDMI. > > The NEC Theatersync gives out its own EDID and both Knoppix 8.1 and 8.2 will > go to x just fine on the VX900. > > > But I've got a wacky Sansui SLED2900 29 inch tv that gives out no EDID at > all on its VGA port and the VX900 thinks that it's got no connection, and > the old "out of range" message. > > I was thinking that maybe I could force-feed the driver an EDID file with a > kernel boot parameter if that would help. > > > from https://wiki.archlinux.org/index.php/kernel_mode_setting > > > drm_kms_helper.edid_firmware=edid/your_edid.bin > drm.edid_firmware=edid/your_edid.bin > > Resolution Name > 800x600 edid/800x600.bin > 1024x768 edid/1024x768.bin > 1280x1024 edid/1280x1024.bin > 1600x1200 edid/1600x1200.bin > 1680x1050 edid/1680x1050.bin > 1920x1080 edid/1920x1080.bin I meant to say, ". . . since OpenChrome DRM is still not mainlined." (In reply to Kevin Brace from comment #41) > > I do not think feeding those EDID parameters really matter since they are > KMS related, and the OpenChrome DDX you are dealing with does not currently > handle KMS since OpenChrome DRM is still mainlined. P Touchman, a few more workarounds discovered after spending a few hours doing some experiments. Here is the procedure. 1) If you are using a windows manager other than LXDE (i.e., Lubuntu's default window manager) for Debian, open a power manager applet and assign the power button to be able to put the computer into sleep 2) Put the computer into sleep by pressing the power button 3) Wake the computer up The power button for LXDE has been broken since Lubuntu 14.04, and this is why I primarily use Xubuntu for OpenChrome development. If you try this workaround, this appears to clear up some registers inside VX900 chipset's DVI / HDMI transmitter that somehow conflicts with VGA. This "scheme" was tested on Xubuntu 18.04 i386 (32-bit). The only side effect of doing this is the loss of VT (i.e., Ctrl + Alt + F1) since the current implementation of OpenChrome DDX does not reinitialize registers for VT after standby resume. However, this workaround is not really needed for Xubuntu 18.04 amd64 (64-bit). What's really different between the two is that i386 version keeps the VT screen at a very low screen resolution (it appears to look like VGA text mode), but amd64 version uses a higher screen resolution graphics mode for the text. Probably what is going on is that OpenChrome DDX is essentially depending on the VGA BIOS to handle VX900 HDMI registers. VGA BIOS dependency is not good since the behavior becomes system dependent. Fundamentally, OpenChrome DDX will need to support VX900 DVI / HDMI transmitter to solve this issue. This will take time since I am not planning to add this feature until OpenChrome DDX Version 0.8 or later (Version 0.7 has not been released yet and probably will not be released for the next several months since there are still some outstanding issues with the code.). (In reply to ptouchman from comment #40) > Hi Kevin, > I did get an interesting bit of kit the other day, an NEC Theatersync video > processor that will tell me what the frequency is of the vga input signal > even if it can't display it. I was thinking that that would tell me what > the frequency is of the "out of range" video. If you feed it a signal that > it doesn't like it gives you a blue screen but the OSD menus and information > still work. > > So the Theatersync can take in VGA up to 1366x768 and rescale it to output > VGA and HDMI. > > The NEC Theatersync gives out its own EDID and both Knoppix 8.1 and 8.2 will > go to x just fine on the VX900. > > Ok, I've finally got a good setup now, I took apart another system for its power supply to get the VX900 going. This NEC theatersync is kind of interesting. Knoppix 8.1 works, Knoppix 8.2 works, but debian 9.3 with latest openchrome git 0.6.175 doesn't work. [ 1119.513] compiled for 1.19.2, module version = 0.6.175 It gets a good EDID, and tries to do 1280x1024 [ 1238.722] (II) CHROME(0): IGA1 Requested Screen Mode: 1280x1024 [ 1238.722] (II) CHROME(0): IGA1 CrtcHTotal: 1728 [ 1238.722] (II) CHROME(0): IGA1 CrtcHDisplay: 1280 [ 1238.722] (II) CHROME(0): IGA1 CrtcHBlankStart: 1280 [ 1238.722] (II) CHROME(0): IGA1 CrtcHBlankEnd: 1728 [ 1238.722] (II) CHROME(0): IGA1 CrtcHSyncStart: 1344 [ 1238.722] (II) CHROME(0): IGA1 CrtcHSyncEnd: 1504 [ 1238.722] (II) CHROME(0): IGA1 CrtcVTotal: 1072 [ 1238.722] (II) CHROME(0): IGA1 CrtcVDisplay: 1024 [ 1238.722] (II) CHROME(0): IGA1 CrtcVBlankStart: 1024 [ 1238.722] (II) CHROME(0): IGA1 CrtcVBlankEnd: 1072 [ 1238.722] (II) CHROME(0): IGA1 CrtcVSyncStart: 1025 But what's weird is if I run via_dump_regs it will say that it's 1280x768. chvt 7; sleep 2; sudo tools/via_regs_dump -p; chvt 2 via-chrome-tool (C) 2009 by VIA Technologies, Inc. This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY SL in System memory: 0x10000000, RTSF in SL: 0x0 Primary Display: H total=1728, active=1280, blank (1288-704), sync(1344-216) V total=1072, active=768, blank (1025-48), sync(1025-3) base_addr=0x05000000, bpp=32 Secondary Display: H total=246, active=242, blank (1530-7924), sync(4081-497) V total=1530, active=2042, blank (1010-2034), sync(2041-19) base_addr=0x00000000, bpp=8 Panel Scaling enabled, mode Interpolation Scaling Factors: horizontal=0, vertical=1707 LVDS Seq Mode: LVDS1 + LVDS2 LVDS CRT Mode: LVDS1 + LVDS2 LVDS Channel 1 Format OpenLDI, Power Down LVDS Channel 2 Format OpenLDI, Power Down But the NEC Theatersync hates the signal and displays a blue screen. I don't know whether to believe the frequencies that it reports since it matches what it says for the text screen. With regards to the Sansui SLED2900 that doesn't work with EDID at all (I'm going to try a new cable today), if the driver doesn't detect a VGA output it won't display anything at all. Once it came up with a no signal I switched the cable to the NEC Theatersync and it said no signal at all so it must not be generating a signal. Created attachment 140139 [details]
NEC Theatersync tries at 1280x1024 doesn't work
P Touchman, I will try a small experiment later today to see if I can disable HDMI. I finally found the VIA Technologies Chrome VX900 HDMI mode setting code for their in-house DDX UMS code path. I have known about its existence for a while, but forgot which source code contained it (VIA has several open source code posted online) and the SSD that had it died (it's not a hard drive, so it no longer "crashes.") 2 months ago (ADATA Ultimate SD800 128 GB SSD). If I get my act together, I think I can develop the code in less than an hour, but if it does not really work, I will let you know that. As a long term solution, I will likely have to implement VX900 chipset HDMI. I will start working on that fairly soon. P Touchman, the tricks I tried did not really work so far, but I am in the process of doing more detailed analysis of which register is causing VGA to go nuts when HDMI is present. It can possibly take several more days. P Touchman, good news! I poured in about 10 hours into this odd issue and figured out why VGA was not working. It turns out HDMI is not at fault directly, but display scaling (pixel interpolation engine mainly meant for FP) and power management hardware registers are set up differently by video BIOS when VGA and HDMI are both connected during boot time. I now know the precise registers that cause the strange display behavior. I will still need some time to figure out how to incorporate the fixes into the code. Created attachment 140176 [details] [review] Fix for the VGA display of ECS VX900-I going bad when a HDMI device is attached P Touchman, I got the patch to fix the bug. The patch was tested on ECS VX900-I, which is very similar to your board. I tested it on both 32-bit (i686) and 64-bit (amd64) Xubuntu 18.04. Theoretically, you can apply this to OpenChrome DDX Version 0.6, but it will be better to apply it to Version 0.6.175. Let me know if the code works. Hi Kevin, That sounds awesome! I will have to try it soon. I'm going out of town for a few days so I'll give it a spin on my return. I did manage to install Ubuntu 18.04 64 bit and it seems to work well on the VE900 with a 1920x1080 TV acting as a monitor. I managed to get mame running with "sudo apt install mame" and was playing about with pacman. It's a bit slow at 1920x1080 resolution, so we can speed it up a bit if we go to 800x600 or 640x480 resolution. mame pacman -autoframeskip -resolution 640x480 -switchres -sdlvideofps -video opengl will give me around 30 frames per second. Interestingly, at 640x480 the "-video soft" gives about the same performance as "-video opengl". For some reason the very top gets chopped off by the TV when I run mame from 1920x1080 mode and put it into 640x480 with the -switchres and -resolution 640x480 options. I activate the mame frameskip display with F11 and it can't be seen. When I run it from 800x600 mode by doing a "xrandr --output VGA-1 --mode 800x600" first the TV will display the mame screen properly. Hi Kevin, You got me inspired so I applied the patch with "patch src/via_display.c thepatchfile" (there's probably an easier way but I'm a noob) and a "make" "sudo service lightdm stop" "sudo cp openchrome_drv.* /usr/lib/xorg/modules/drivers" sudo reboot and TADA! IT WORKS!!!!!! YAY! Now that my Debian 9.3 32 bit is working (YAY!), I thought I'd try to install mame from the "unstable" repository. What's interesting is that the performance is much better under Debian 9.3. In looking at the frameskip display with F11 it's running at pretty much 100% without skipping frames at 640x480. I'd say that the video performance on the VE900 is easily double what I saw on Ubuntu 18.04 64 bit. I wonder if it'd be any better performance with more than one memory DIMM if it were running Dual Channel Memory. mame -switchres -resolution 640x480 pacman I still had the same issue about going from 1920x1080 --> 640x480 (top line chopped off) 800x600 --> 640x480 whole screen displayed Thanks for finding and fixing the bug!!!! I tried some more fiddling and was able to get a display on my Sansui SLED2900 that has no EDID on the VGA-1 (for whatever reason, I've tried a whole bunch of different cables.) I was able to get the Sansui to work with this workaround: I boot debian 9.3 with these additional grub command line parameters: drm_kms_helper.firmware_edid=edid/1280x1024.bin video=1280x1024e and it acts differently than expected, but it tries to do mode 1152x864 (why 1152x864 I don't know) I get a blank screen with "Not supported" on the Sansui. I go to a text terminal with CTRL+ALT+1, login and try: "xrandr -d :0" and it gives me some "Invalid MIT-Magic-cookie" message. I stop the lightdm with "sudo services lightdm stop" which kills the xserver. Then I do a startx from the command line. I switch to a text terminal with CTRL+ALT+2, login and try: "xrandr -d :0" and now I have access to the x server and it tells me the valid modes available, 1360x768 is the native resolution of my Sansui. "xrandr -d :0 --output VGA-1 --mode 1360x768" gives me the message Xrandr: Configure crtc 0 failed so "chvt 1; sleep 2; xrandr -d :0 --output VGA-1 --mode 1360x768" works and I get a visible display on my Sansui. Yes! I'm going to post the xorg log. Created attachment 140181 [details]
xorg on Sansui SLED2900 edid 1280x1024.bin no display
Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-4-686 root=/dev/sdb2 ro quiet drm_kms_helper.edid_firmware=edid/1280x1024.bin
tries to do 1024x768 but no display
[ 19.876] (II) CHROME(0): EDID for output VGA-1
[ 19.876] (II) CHROME(0): Output VGA-1 disconnected
[ 19.876] (WW) CHROME(0): No outputs definitely connected, trying again...
[ 19.877] (II) CHROME(0): Output VGA-1 disconnected
[ 19.877] (WW) CHROME(0): Unable to find connected outputs - setting 1024x768 initial framebuffer
Created attachment 140182 [details]
xorg on Sansui SLED2900 edid 1280x1024.bin specify video=1280x1024e no display
[ 18.301] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-4-686 root=/dev/sdb2 ro quiet drm_kms_helper.edid_firmware=edid/1280x1024 video=1280x1024e
specify video=1280x1024e and drm_kms_helper.edid_firmware=edid/1280x1024
get VGA-1 connected, but wants to display 1152x864 (not supported by SLED2900)
[ 19.673] (II) CHROME(0): Not using default mode "1024x768" (doublescan mode not supported)
[ 19.673] (II) CHROME(0): Printing probed modes for output VGA-1
[ 19.673] (II) CHROME(0): Modeline "1360x768"x59.8 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync (47.7 kHz d)
[ 19.673] (II) CHROME(0): Modeline "1152x864"x60.0 81.62 1152 1216 1336 1520 864 865 868 895 -hsync +vsync (53.7 kHz d)
[ 19.673] (II) CHROME(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz d)
[ 19.673] (II) CHROME(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz d)
[ 19.673] (II) CHROME(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz d)
[ 19.673] (II) CHROME(0): Output VGA-1 connected
[ 19.673] (II) CHROME(0): Using exact sizes for initial modes
[ 19.673] (II) CHROME(0): Output VGA-1 using initial mode 1152x864 +0+0
Created attachment 140183 [details]
xorg on Sansui SLED2900 edid and video then used xrandr to set 1360x768 works
[ 3941.894] Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-4-686 root=/dev/sdb2 ro quiet drm_kms_helper.edid_firmware=800x600.bin video=800x600e
[ 3942.660] (II) CHROME(0): Printing probed modes for output VGA-1
[ 3942.660] (II) CHROME(0): Modeline "1360x768"x59.8 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync (47.7 kHz d)
[ 3942.660] (II) CHROME(0): Modeline "1152x864"x60.0 81.62 1152 1216 1336 1520 864 865 868 895 -hsync +vsync (53.7 kHz d)
[ 3942.660] (II) CHROME(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz d)
[ 3942.660] (II) CHROME(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz d)
[ 3942.660] (II) CHROME(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz d)
[ 3942.660] (II) CHROME(0): Output VGA-1 connected
[ 3942.660] (II) CHROME(0): Using exact sizes for initial modes
[ 3942.660] (II) CHROME(0): Output VGA-1 using initial mode 1152x864 +0+0
Then was able to set the resolution with xrandr
CTRL+ALT+F1 and login
sudo services lightdm stop
startx
(get blank display)
CTRL+ALT+F2 and login
chvt 1; sleep 2; xrandr -d :0 --output VGA-1 --mode 1360x768
[ 4011.653] (II) CHROME(0): Modeline "1360x768"x0.0 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync (47.7 kHz)
[ 4011.653] (II) CHROME(0): CrtcHDisplay: 0x550
[ 4011.653] (II) CHROME(0): CrtcHBlankStart: 0x550
[ 4011.653] (II) CHROME(0): CrtcHSyncStart: 0x598
[ 4011.653] (II) CHROME(0): CrtcHSyncEnd: 0x620
[ 4011.653] (II) CHROME(0): CrtcHBlankEnd: 0x6f0
[ 4011.653] (II) CHROME(0): CrtcHTotal: 0x6f0
[ 4011.654] (II) CHROME(0): CrtcHSkew: 0x0
[ 4011.654] (II) CHROME(0): CrtcVDisplay: 0x300
[ 4011.654] (II) CHROME(0): CrtcVBlankStart: 0x300
[ 4011.654] (II) CHROME(0): CrtcVSyncStart: 0x303
[ 4011.654] (II) CHROME(0): CrtcVSyncEnd: 0x30d
[ 4011.654] (II) CHROME(0): CrtcVBlankEnd: 0x31e
[ 4011.654] (II) CHROME(0): CrtcVTotal: 0x31e
P Touchman, the following commit incorporates fixes to the code. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=88391a2625d39fe444b1d48d6301dbe90e267743 I am ready to close the bug. Regarding the top getting chopped off, is there a setting that allows you to adjust the aspect ratio of the picture being displayed? I know that I have had this issue when I displayed the HDMI signal coming out of VX900 chipset with one 720p HDTV. Unfortunately, this TV can change the display aspect ratio via a setup screen that can only be reached by entering it from the remote control. It was an abandoned TV (and 100% working) and the previous owner did not leave the remote control with the TV. (In reply to ptouchman from comment #51) > Hi Kevin, > > That sounds awesome! I will have to try it soon. I'm going out of town for > a few days so I'll give it a spin on my return. > > I did manage to install Ubuntu 18.04 64 bit and it seems to work well on the > VE900 with a 1920x1080 TV acting as a monitor. > > I managed to get mame running with "sudo apt install mame" and was playing > about with pacman. > > It's a bit slow at 1920x1080 resolution, so we can speed it up a bit if we > go to 800x600 or 640x480 resolution. > > mame pacman -autoframeskip -resolution 640x480 -switchres -sdlvideofps > -video opengl > > will give me around 30 frames per second. Interestingly, at 640x480 the > "-video soft" gives about the same performance as "-video opengl". > > > For some reason the very top gets chopped off by the TV when I run mame from > 1920x1080 mode and put it into 640x480 with the -switchres and -resolution > 640x480 options. I activate the mame frameskip display with F11 and it > can't be seen. > > When I run it from 800x600 mode by doing a "xrandr --output VGA-1 --mode > 800x600" first the TV will display the mame screen properly. (In reply to Kevin Brace from comment #59) > Regarding the top getting chopped off, is there a setting that allows you to > adjust the aspect ratio of the picture being displayed? > I know that I have had this issue when I displayed the HDMI signal coming > out of VX900 chipset with one 720p HDTV. > Unfortunately, this TV can change the display aspect ratio via a setup > screen that can only be reached by entering it from the remote control. > It was an abandoned TV (and 100% working) and the previous owner did not > leave the remote control with the TV. > Hi Kevin, Yes, some TVs want to do overscan on input signals which is really annoying. One TV in particular I remember would overscan a 1920x1080 signal which to me made no sense at all. So I was able to "defeat" the overscan by using a custom resolution of 1920x1079 http://ptouchman.blogspot.com/2017/04/fixing-hdmi-overscan-at-1920x1080-on.html You might be able to find a universal remote that sets the aspect ratio, the logitech harmony has a huge database. Or buy a replacement remote on ebay (it's nice to have the exact remote) Sometimes the cost on ebay is high though. On this particular TV, the top getting chopped off isn't helped by changing the aspect ratio as it goes from top chopped off narrow to top chopped off wide 8-) Are you able to change the screen resolution properly through those applets that comes with the OS? (In reply to ptouchman from comment #53) > Now that my Debian 9.3 32 bit is working (YAY!), I thought I'd try to > install mame from the "unstable" repository. > > What's interesting is that the performance is much better under Debian 9.3. > In looking at the frameskip display with F11 it's running at pretty much > 100% without skipping frames at 640x480. > > I'd say that the video performance on the VE900 is easily double what I saw > on Ubuntu 18.04 64 bit. > > I wonder if it'd be any better performance with more than one memory DIMM if > it were running Dual Channel Memory. > > > mame -switchres -resolution 640x480 pacman > > I still had the same issue about going from > > 1920x1080 --> 640x480 (top line chopped off) > 800x600 --> 640x480 whole screen displayed > > > > Thanks for finding and fixing the bug!!!! Although you no longer need to apply the patch since the changes went into the upstream repository code, this is how I apply the patch.
patch -p 1 < ("File Name of the Patch")
Place the patch under /xf86-video-openchrome directory.
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.