https://bugs.freedesktop.org/show_bug.cgi?id=46525
--- Comment #9 from Michel Dänzer mic...@daenzer.net 2012-02-24 02:05:17 UTC
---
(In reply to comment #5)
Does your drm Git snapshot have commit
9b3ad51ae5fd9654df8ef75de845a519015150bb
('radeon: fix pitch alignment for scanout buffer')?
https://bugs.freedesktop.org/show_bug.cgi?id=46525
Dejan Noveski d...@atomidata.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Hi Alex,
A few weeks ago I spent some time trying to get my sam440ep PPC board to
work with a recent kernel/debian distro. I discovered a bug causing it
to crash. It's a regression of commit 82f12e5a40c1fbcb91910a0f8b725c34fff02aae
from January 2009. Clearly, this board isn't used very often :-)
On Fre, 2012-02-24 at 11:24 +0100, Hans Verkuil wrote:
I've also tried to get drm to work with this board, but unfortunately the
colors
have the wrong endianness and I don't really have any idea how to fix that (or
even where to look for that matter). For the record, this board has a ATI
On Friday, February 24, 2012 11:58:59 Michel Dänzer wrote:
On Fre, 2012-02-24 at 11:24 +0100, Hans Verkuil wrote:
I've also tried to get drm to work with this board, but unfortunately the
colors
have the wrong endianness and I don't really have any idea how to fix that
(or
even
On Fre, 2012-02-24 at 12:33 +0100, Hans Verkuil wrote:
On Friday, February 24, 2012 11:58:59 Michel Dänzer wrote:
On Fre, 2012-02-24 at 11:24 +0100, Hans Verkuil wrote:
I've also tried to get drm to work with this board, but unfortunately the
colors
have the wrong endianness and
On Fre, 2012-02-24 at 12:46 +0100, Hans Verkuil wrote:
On Friday, February 24, 2012 12:41:15 Michel Dänzer wrote:
Under what circumstances exactly you're seeing wrong colours:
In console and/or in X?
X. The console seems to be fine.
If the latter, with all apps or only
On Friday, February 24, 2012 13:19:56 Michel Dänzer wrote:
On Fre, 2012-02-24 at 12:46 +0100, Hans Verkuil wrote:
On Friday, February 24, 2012 12:41:15 Michel Dänzer wrote:
Under what circumstances exactly you're seeing wrong colours:
In console and/or in X?
X. The console
On Fre, 2012-02-24 at 13:25 +0100, Hans Verkuil wrote:
On Friday, February 24, 2012 13:19:56 Michel Dänzer wrote:
On Fre, 2012-02-24 at 12:46 +0100, Hans Verkuil wrote:
On Friday, February 24, 2012 12:41:15 Michel Dänzer wrote:
Under what circumstances exactly you're seeing wrong
Alex Deucher wrote:
region 0 is always the frame buffer and region 2 is always mmio.
radeontool and avivotool should be cleaned up the same way radeonreg
is.
Thanks, makes perfect sense. Here's a reroll that does that.
The motivation is still patches 7 (libpciaccess API churn) and 10
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
helper 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
In the construct
for each PCI device:
if PCI ID is interesting:
long block of code to handle
the detected device
the if with long body leaves the reader in suspense about what will
happen when the PCI ID is not interesting.
If only one card is present but --skip=n was supplied, it is more
intuitive to error out than to guess which earlier card the user
meant.
Compare commit a8ce2f23c589 (radeontool: completely skip early cards
with --skip, 2010-03-23).
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Jonathan Nieder wrote:
If only one card is present but --skip=n was supplied, it is more
intuitive to error out than to guess which earlier card the user
meant.
Oops, sent the wrong version of this patch. Please squash in the
following for sanity. Later patches assume the following has been
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
18 matches
Mail list logo
