ATI 5770 (probably all ati cards) lacks decent video mode table

[markg85]

Hi,

I recently bought a sapphire 5770 card and was fully aware that it probably would not work with a linux distribution that has a "to new" xorg (7.5). I also knew it was likely not going to be supported by the opensource radeon driver (yet) but i bought it anyway.

Now the big surprise came with VESA. I would have expected VESA to just fully run with my full screen resolution (1680x1050) but it sadly didn't.

The reason it won't work at that resolution is because our lovely ATi fellows have a heavily outdated modes list for the video card.. and vesa only runs modes that are in that list. My list:

640x400-8, 0x0100
640x480-8, 0x0101
800x600-8, 0x0103
1024x768-8, 0x0105
1280x1024-8, 0x0107
640x480-15, 0x0110
640x480-16, 0x0111
800x600-15, 0x0113
800x600-16, 0x0114
1024x768-15, 0x0116
1024x768-16, 0x0117
1280x1024-15, 0x0119
1280x1024-16, 0x011a
320x200-15, 0x010d
320x200-16, 0x010e
320x200-32, 0x0120
320x240-8, 0x0193
320x240-16, 0x0195
320x240-32, 0x0196
512x384-8, 0x01b3
512x384-16, 0x01b5
512x384-32, 0x01b6
640x350-8, 0x01c3
640x350-16, 0x01c5
640x350-32, 0x01c6
720x400-8, 0x0133
720x400-16, 0x0135
720x400-32, 0x0136
1152x864-8, 0x0153
1152x864-16, 0x0155
1152x864-32, 0x0156
1280x960-8, 0x0163
1280x960-16, 0x0165
1280x960-32, 0x0166
640x480-32, 0x0121
800x600-32, 0x0122
1024x768-32, 0x0123
1280x1024-32, 0x0124
1400x1050-8, 0x0143
1400x1050-16, 0x0145
1400x1050-32, 0x014

As you can see my resolution (1680x1050) is not in there which causes xorg to refuse to set the 1680x1050 resolution.

After i found this out i mailed Sapphire about it (the card is manufactured by them) but they told me it's not a vbios issue and that i should contact ATi about it. So i did contact ATI but all i get back from them is a message telling me that my message is directed to the ati driver team and a bunch of links if i have linux driver problems.. So nothing usefull since this has nothing to do with the driver.

So, now i call on that ati fellow browsing here, bridgman, to please read this and please do update the modes list! Add support for modes that are common today. I can live with no catalyst (or radeon) driver in linux but i can't with a stretched resolution! That just forces me to either painfully downgrade xorg or to use windows.

Please please please do something about this!!!

O btw. Am i right that this should be fixed in the ati vbios? (since sapphire told me that it's NOT a vbios issue)

If i had a inter graphics card the resolution would be simple: 915resolution ... If an application like that exists for ATi as well please do tell me.

I hope to see a reply here (specially from bridgman).
Any other solutions (that don't require money) are welcome as well.

Regards
Mark

[markg85]

Odd.. why can't i edit my own thread?

Anyway. My solution for this issue would be (if it's the vbios) that ATi releases a VBIOS with the following resolutions in the modes table: http://en.wikipedia.org/wiki/List_of_common_resolutions just add ALL the common resolutions. If you don't want to do it give me the source and i will do it. It can't be that hard.

[Hoodlum]

Just posting to confirm the issue. I have the same problem with a powercolor 5770.

[bridgman]

I haven't looked at this for years, but my understanding was that VESA bios tables were always quite limited in terms of available resolutions. IIRC the standard stopped around 1280x960 or so.

I'll ask what would be involved in adding more resolutions. The additional modes would go in the BIOS image, which is fixed size, so we would probably have to take something out to make room for the new modes. The key challenge will probably be navigating through all the different production test environments our customers use so that we don't end up taking out a mode they need in order to add a mode they don't care about.

The editing lockout is an experiment to reduce the spam count on the board AFAIK.

[markg85]

I haven't looked at this for years, but my understanding was that VESA bios tables were always quite limited in terms of available resolutions. IIRC the standard stopped around 1280x960 or so.

I'll ask what would be involved in adding more resolutions. The additional modes would go in the BIOS image, which is fixed size, so we would probably have to take something out to make room for the new modes. The key challenge will probably be navigating through all the different production test environments our customers use so that we don't end up taking out a mode they need in order to add a mode they don't care about.

The editing lockout is an experiment to reduce the spam count on the board AFAIK.

Well, (sorry to grab in your biggest oponent) nvidia did support 1680x1050 but since my card was kinda old (8600GT) i decided to "upgrade" my card not knowing that i would go down in available resolutions without the catalyst drivers...

As for the resolutions. You don't _need_ to support _all_ the resolutions from the wiki link i posted.. Just look at the "common" ones in that list and remove out the ones that are less common. 1680x1050 is one that certainly is common but a resolution like 1220x160 is far from common. I think you can safely remove anything under 640x480 perhaps even all under 800x600

And a fixed sized vbios.. There must be ~1 KB left to add those resolutions!

Last question. Is it possible to make a "915resolution" like program for ATi cards? since that would probably solve my issue and solves the ati issue to release a new vbios.

But again (can't stress this enough) living without readeon or catalyst driver is fine but the resolution just HAS to be supported. Isn't there a way to define a minimal and maximal resolution the card can handle and allow vesa (and drivers alike) to use anything in between if they want to..? For example if the card can support 100x100 px till 100000x1000000 px then i see absolutely no point in adding every resolution in between to a list.. If vesa knows that 100000x1000000 is the max then surely it can use 1680x1050.. this would probably require some updates in the ati vbios and the vesa driver though.

[bridgman]

As for the resolutions. You don't _need_ to support _all_ the resolutions from the wiki link i posted.. Just look at the "common" ones in that list and remove out the ones that are less common. 1680x1050 is one that certainly is common but a resolution like 1220x160 is far from common. I think you can safely remove anything under 640x480 perhaps even all under 800x600

The lowest res modes are the most likely to be used in production test, since they lend themselves to reliable automated analysis of the analog video output.

We don't support 1220x160 today, do we ?

And a fixed sized vbios.. There must be ~1 KB left to add those resolutions!

You're joking, right ? BIOS developers jump through hoops to save 10 or 20 bytes for a new option. This has been going on for years. The cost difference between 64K and 128K ROMs has finally become small enough that we are able to move to larger ROMs on the high end cards without too much hate from the board manufacturers, so there is hope.

Last question. Is it possible to make a "915resolution" like program for ATi cards? since that would probably solve my issue and solves the ati issue to release a new vbios.

Yeah, it's called the open source driver. Stay tuned.

But again (can't stress this enough) living without readeon or catalyst driver is fine but the resolution just HAS to be supported. Isn't there a way to define a minimal and maximal resolution the card can handle and allow vesa (and drivers alike) to use anything in between if they want to..? For example if the card can support 100x100 px till 100000x1000000 px then i see absolutely no point in adding every resolution in between to a list.. If vesa knows that 100000x1000000 is the max then surely it can use 1680x1050.. this would probably require some updates in the ati vbios and the vesa driver though.

I don't think the VESA API works that way. The app/driver calls VBE and asks it to enumerate all of the modes, then the driver passes the enumeration variable back in a subsequent VBE call.

[bridgman]

Sigh... I sure miss editing

What I was trying to say for the third question was that releasing a simple resolution-setter and releasing an initial open source driver would probably take roughly the same time, and that the open source driver would probably be a lot more broadly useful.

[markg85]

The lowest res modes are the most likely to be used in production test, since they lend themselves to reliable automated analysis of the analog video output.

We don't support 1220x160 today, do we ?

typo.. it was from the common list and was meant to be 120x160

You're joking, right ? BIOS developers jump through hoops to save 10 or 20 bytes for a new option. This has been going on for years. The cost difference between 64K and 128K ROMs has finally become small enough that we are able to move to larger ROMs on the high end cards without too much hate from the board manufacturers, so there is hope.
[/qoute]
Artually not. We have gigabytes today and even video cards go over a gigabyte these days and you tell me the bios is still stored on 64K ROM.. i say it's time to reinvent that ancient trick so space is less of an issue with biosses. (just looking at that as an outsider. I know nothing about bios programming but i do know that the firmware in my router has a lot more then 64K for it's firmware and that router only costs €60!

Yeah, it's called the open source driver. Stay tuned.

-_- oke...

I don't think the VESA API works that way. The app/driver calls VBE and asks it to enumerate all of the modes, then the driver passes the enumeration variable back in a subsequent VBE call.

Don't know. just guessing in this area as well. to me (as a programmer!) it just seems odd that resolutions have to be in a list. Probably an ancient decission from a decade ago that would, if made now, be down completely different.

[bridgman]

More like two decades ago

[markg85]

More like two decades ago

Then it's certainly time to rethink it.
The only thing that lives as long as that in linux is linux itself if you ask me.. And the entire graphics stack has undergone major changes in the recent years with another big one to come in the future: Galium3D

So, to me, it only seems logical that this video mode table is going to be revised as well.