"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 f
Add assertions to all functions that assume the caller has called
map_radeon_cntl_mem and radeon_cntl_mem is non-NULL. Use assert()
uniformly for this, replacing the more verbose
if (!radeon_cntl_mem)
die("internal error");
since assert() tends to produce more useful outp
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: cann
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 -Wdeprecated-declaration
Trying to guess which region is which based on size is needlessly
error-prone and complicated.
Region 0 is always the frame buffer and region 2 is always mmio.
radeonreg already hard-codes the appropriate region numbers. This
patch teaches radeontool and avivotool to do the same.
Suggested-by: A
This just unindents the code some more.
Signed-off-by: Jonathan Nieder
---
avivotool.c | 30 +++---
radeonreg.c | 24
radeontool.c | 44 +---
3 files changed, 48 insertions(+), 50 deletions(-)
diff
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 be
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
---
avivotool.c |6 +++---
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.
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
---
avivotool.c |2 +-
radeonreg.c |2 +-
2 files chang
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 t
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
(unf
On Fri, Feb 24, 2012 at 5:24 AM, Hans Verkuil wrote:
> 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
> f
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
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?
> >
>
On Friday, February 24, 2012 12:41:15 Michel Dänzer wrote:
> 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
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
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
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
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 A
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 :-)
https://bugs.freedesktop.org/show_bug.cgi?id=46525
Dejan Noveski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=46525
--- Comment #9 from Michel Dänzer 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')?
Note that this fix
23 matches
Mail list logo
