Created attachment 15099 [details]
Sample Corrupted screen
Virtual PC 2007, emulates a "S3 Inc. 86c764/765 [Trio32/64/64V+]" PCI card (5333:8811).
The implementation doesn't supports 24bits mode and this is supposed to be described in ROM, according to .
Because Xorg seems to inaccurately reports that this S3 card supports 24bpp mode, some distribution (including Debian, Ubuntu) try to configure the X display at 24bpp by default.
This causes the screen to be corrupted (see attached picture).
I'm not sure whether there's actually anything you can do about it.
P.S. I should be able to provide access to a VirtualPC box, i you want/need.
 Virtual PC 2007 is a free (as in "free beer") Virtualistion tool from Microsoft.
keywords: vpc2005 ; vpc2007 ; Virtual PC 2005
I'm working on this problem but only for Trio64V2. I added support 24 bpp, 32 bpp (24 bpp without 2D acceleration - something won't work), Xvideo. I'm not ready for commit my code. I think these changes will be available around version 0.7.0.
Please, let me see your xorg.conf, Xorg.*.log and 'lspci -v' output when using 24-bit depth in xorg.conf.
Also try to disable hardware acceleration support with option "noaccel" :
Created attachment 17581 [details]
default xorg.conf (xserver-xorg-1.4.2 + xserver-xorg-0.6.0)
Created attachment 17582 [details]
default xorg.log (xserver-xorg-1.4.2 + xserver-xorg-0.6.0)
Created attachment 17583 [details]
lspci -nnv output, for Virtual PC 2007 (18.104.22.168)
Created attachment 17584 [details]
s3+noaccel xorg.conf (xserver-xorg-1.4.2 + xserver-xorg-0.6.0)
Created attachment 17585 [details]
s3+noaccel xorg.log.log (xserver-xorg-1.4.2 + xserver-xorg-0.6.0)
Created attachment 17586 [details]
s3+16bpp xorg.conf (xserver-xorg-1.4.2 + xserver-xorg-0.6.0)
Created attachment 17587 [details]
s3+16bpp xorg.log (xserver-xorg-1.4.2 + xserver-xorg-0.6.0)
(I've upgraded to xorg 7.3 : xserver-xorg_1.4.2 + xserver-xorg-video-s3_0.6.0)
I've attached the results of three tests :
1. "default xserver" : I've reconfigured Xorg. That's an empty xorg.conf : don't work.
2. "s3+noaccel" : I've added "Driver=s3" and "noaccel" option :don't work.
3. "s3+bpp16" : I've added "Driver=s3" and set "DefaultDepth=16" : work.
> (I've upgraded to xorg 7.3 : xserver-xorg_1.4.2 + xserver-xorg-video-s3_0.6.0)
Thank you for logs.
I think that the explanations from your original post are not relevant to the problem. Your screenshot shows that problems more probably lays in timings (CRTC) programming. 32-bit framebuffer (24-bit colour) is supported by default (see driver messages: "(--) Depth 24 pixmap format is 32 bpp", ), and enabling 24-bit colour/24 bpp requires special option.
Have you skills to compile driver by yourself? I recommend you to try the latest driver from Git. Some timings errors with 24-bit colour depth (24/32-bit framebuffer mode) for TRIOs was fixed there. May be these improvements will be helpful in your case.
If you are not able to compile driver, I can send you binary s3 driver which was compiled for Debian Etch.
I would prefer if you could send me a compiled module.
Created attachment 17623 [details]
tested "git" driver works.
I have tested Evgeny M. Zubok's driver... it works (in limited resolution, though).
see log file attached.
Identifier "Default Screen"
Device "S3 Inc. 86c764/765 [Trio32/64/64V+]"
Monitor "Generic Monitor"
Modes "1280x1024" "1024x768" "800x600" "640x480"
Identifier "S3 Inc. 86c764/765 [Trio32/64/64V+]"
Identifier "Generic Monitor"
(In reply to comment #13)
> Created an attachment (id=17623) [details]
> tested "git" driver works.
> xorg.conf :
> Section "Screen"
> Identifier "Default Screen"
> Device "S3 Inc. 86c764/765 [Trio32/64/64V+]"
> Monitor "Generic Monitor"
> DefaultDepth 24
> SubSection "Display"
> Depth 24
> Modes "1280x1024" "1024x768" "800x600" "640x480"
"1280x1024"/32bpp mode requires greater size of video RAM than available (VirtualPC has only 4Mb), and we need in this case 1280*1024*(32-bit/8)= 5Mb. This mode can be used with 24bpp (packed colour) but VirtualPC doesn't support this colour depth.
"1024x768"/32bpp framebuffer can be placed in videoram (1024*768*(32bit/8)=3 Mb), but it requires interlaced mode in accordance to S3 trio's whitepaper. It seems that driver still has the problems with interlaced modes. I hope it will be solved in near future.
Could you look at the picture 800x600 (32-bit)? There was bug with S3 Trio64V2 when the few right pixels are cutted. In 8-bit mode there are no eaten pixels, in 16-bit mode there is one eaten pixel and in 32-bit mode there is four eaten pixels. I fix this bug only for Trio64V2 but not for the other Trios. I need some data from Trio owners and VirtualPC too, but I haven't MS Windows to test. Does this bug take place in your case?
> Could you look at the picture 800x600 (32-bit)? There was bug with S3 Trio64V2
> when the few right pixels are cutted. In 8-bit mode there are no eaten pixels,
> in 16-bit mode there is one eaten pixel and in 32-bit mode there is four eaten
> pixels. I fix this bug only for Trio64V2 but not for the other Trios. I need
> some data from Trio owners and VirtualPC too, but I haven't MS Windows to test.
> Does this bug take place in your case?
I mean here that whole right edge of the picture is cut by few pixels.
Created attachment 17625 [details]
no cropped pixels at the right of the screen.
I have no missing pixels.
> I have tested Evgeny M. Zubok's driver... it works (in limited resolution,
I've added interlace mode support to s3 driver, so this bug can be finally closed. Once again, according to whitepaper, S3 Trio64V+ with 4Mb RAM suports the 1024x768 resolution in 32 bpp framebuffer mode only with interlaced mode. To enable this mode you need to provide suitable ModeLine with flag "Interlace" in Monitor section.