If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

Besides other stupid issues with the driver: why are the FireGL ids removed when they could be patched back easyly? I think it should be the users choice which driver they want to use - even buggy ones. And another one: why not use lzma compression? I have sample scripts that can already repack any driver (with static decoder) and its size drops dramatically. Example:

Comment

Why do the KB numbers in the driver's release notes not directly link to the KB articles?

Why is the card state (sometimes?) not reinitialized on reboot:
1. related to the vesa framebuffer console bug, when I reboot (via ctrl+alt+del) sometimes the 'dead' state that caused me to need to reboot persists forcing another restart
2. possibly X.org's fault(?) upon reload of X.org/gdm I see a garbled version of the previous state of the screen (ie, what was shown before the reboot), then it loads as normal. Contrasted with windows where that doesn't happen. This happens in versions of the driver with or without the vesa framebuffer issue.

How does the driver team ascribe priority to what will be developed in each release?

What code management do they use and are team members allowed to keep private branches in order to target specific issues (like new kernel or X.org support)?

Related to ZedDB's question:
Are the devs regularly frustrated by having fixed issues but not being able to push them out to their users because of the dev cycle (or other restrictions) imposed by management?

How much easier would development be if there were lower-end GPUs targeted specifically for linux (similar to the Intel GPU offerings)?