© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Hello Tormod,
thanks for your comments and tests! Are you more deeply involved into the calculation methods for these savage drivers?
In fact, on my system I had to remove the 7-pixel offset to get the screen full in width.
I'm sorry, at the moment I don't have a lot of time for doing an official commit - but if it may take some time, I can keep an eye on it.
I'd like to improve the driver further, there are several open issues:
- when switching to TV output, similar clipping as I had experienced (and resolved) it on the LCD occurs again, depending on the video source resolution --> maybe an intermediate calculation similar to the expansion code should be applied? Additionally, there is NO resolution that fits TV out perfectly. 800x600 is closest, but the right and bottom ends are not displayed. This looks like even the basic image buffer might need scaling.
- the driver (or the HW) is not able to scale a video DOWN. If there is a display window smaller than the source resolution, it is clipped. Maybe an integer/float issue?
- when using the s3switch tool to use TV mode, this setting is not stored correctly / permanently in any way. Power management interventions or even players like VLC (which I need due to performance issues) disable the TV out and put garbage on the LCD. I have to enter "s3switch lcd" blindly to regain anything visual from the system. The current workaround with VLC is to start and pause a video while still using LCD or CRT, then switch to TV. The simple "play" command from stop state in VLC results in the garbage mentioned...
- I have a little bit of hope to be able to boost the XVideo source window limit from 1024x1024 up to something larger, at least 1280x1280 to allow larger images (which are only data bloat and often the added "resolution" is decreased by compression artifacts, but can sometimes be found) to be displayed.
It would be great if we could improve this driver. The machines using the hardware are great tools, very power-saving and quiet, and the basic acceleration of the savage as well as the TV out rendering are quite nice.
Do you have access to any specs of the S3 chips? And/or can you explain the data formats to me, especially this integer/float issue and "artificial" floats created by dividing an integer data type to a fraction? I searched the internet a lot, but could not find a definite clue. Often such formats are no "standards" but simply a way to resolve a problem - I work a lot with controllers which are only able to use integers, often enough only 16 bit embedded systems... but in these application I can look at the code and see how the numbers are used. X11 is also open source, but a big bunch... so it would be great if you could help me here.
Best regards,
Hans-Juergen