https://bugs.freedesktop.org/show_bug.cgi?id=46270
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=46314
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=42852
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
CC||pu...@mac.com
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=42852
--- Comment #7 from Alex Deucher ag...@yahoo.com 2012-02-20 07:32:19 PST ---
(In reply to comment #6)
If I understand this correctly, there is no plan to support FreeBSD for the
Radeon 6310 HD then?
No more than is currently supported unless
https://bugs.freedesktop.org/show_bug.cgi?id=34486
Tobias Diedrich ranma+freedesk...@tdiedrich.de changed:
What|Removed |Added
CC|
Wow, I can only second this.
I've been wondering what part of the last upgrade made my desktop so
glacially slow and finally found that flipping the ColorTiling
option to false makes a big difference.
Everything feels at least an order of magnitude faster now.
With ColorTiling enabled I had
Hi Tormod,
Tormod Volden wrote:
[Subject: Only print current status in usage() if we are root]
Sorry to take so long to get to this. Here's a series that covers
two topics. Patches 4 and 5/5 are intended to be in the same spirit
and mostly cover the same ground as your patches concerning
After radeontool-1.6.0~28 (add more ram dumping stuff) avivotool
tries to detect a Radeon unconditionally, even for the romtables
subcommand that doesn't require one. To keep avivotool useful when
there is an error detecting a card, the patch changed the fatal error
codepath to keep going rather
It's safer not to continue once in an erroneous situation.
This reverses a change made in radeontool-1.6.0~28 (add more ram
dumping stuff) and makes the behavior of avivotool match radeontool
again.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
avivotool.c |2 +-
radeonreg.c |2
Just like radeontool, avivotool should not blindly fall back to
region 0 when the expected memory areas cannot be found. Noticed by
code inspection. (Compare commits 51a87cf0 and 7e3e9808.)
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
avivotool.c | 29 ++---
Ever since it was introduced in libpciaccess 0.10.0 four years ago,
pci_device_map_range has been the preferred way to map a PCI region
and pci_device_map_region has been a deprecated backward-compatibility
shim. Switch over. No functional change intended.
Noticed by gcc
Introduce a die_error() helper that includes strerror in a fatal
error message and use it where possible. In particular, when
running radeontool as non-root, instead of the cryptic
fatal error: mapping ctrl region
the operator will get a more helpful diagnosis:
fatal error:
radeontool --help tries to map the control region in order to print
dac and light state indicators embedded in the usage message.
Unfortunately that means that running radeontool --help without
sufficient privileges errors out without a usage message that would
have hinted at what the tool is for
13 matches
Mail list logo
