On Tue, 08 Feb 2011 08:52:52 +1000, Dave Airlie wrote:
> On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
> > is this a problem? before trying to submit a solution I wanted to make sure
> > with the experts
> >
> > it seems open_count isn't locked and can cause problems
> >
> > and if it
On Monday, February 07, 2011, Matthew Garrett wrote:
> On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
>
> > I'm not familiar with video devices, but I agree, this situation does
> > feel broken. Is it the case that there's a PCI device as well as an
> > ACPI namespace Device for
On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
> I'm not familiar with video devices, but I agree, this situation does
> feel broken. Is it the case that there's a PCI device as well as an
> ACPI namespace Device for the same piece of hardware? If so, I assume
> the reason for
https://bugs.freedesktop.org/show_bug.cgi?id=32350
--- Comment #34 from Edgar Villanueva 2011-02-07
19:44:26 PST ---
2.6.34.8 exhibits the same problems.
I found the kernel source for fedora 11 that worked but then I realized that I
didn't use DRM there as I had problems.
I build the 2.6.30
On 02/06/2011 08:09 PM, Dave Airlie wrote:
> This abstracts the pci/platform interface out a step further,
> we can go further but this is far enough for now to allow USB
> to be plugged in.
>
> The drivers now just call the init code directly for their
> device type.
>
> Signed-off-by: Dave
On Sunday, February 06, 2011 04:34:43 pm Rafael J. Wysocki wrote:
>
> Still, IMO, there is a design issue in the entire ACPI subsystem, because the
> idea of "ACPI device" really is not well defined, so to speak. Sometimes
> they are just "device interfaces" that can be used to ask the firmware
https://bugs.freedesktop.org/show_bug.cgi?id=34008
Summary: r600g: piglit failure (regression)
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
PPC Mac cards do not provide connector tables in
their vbios. Their connector/encoder configurations
must be hardcoded in the driver.
verified by nyef on #radeon
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c | 47
This adds an initial framework to plug USB graphics devices
into the drm/kms subsystem.
I've started writing a displaylink driver using this interface.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/drm_stub.c |1 +
drivers/gpu/drm/drm_usb.c | 117
This abstracts the pci/platform interface out a step further,
we can go further but this is far enough for now to allow USB
to be plugged in.
The drivers now just call the init code directly for their
device type.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_drv.c | 43
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #24 from T?r?k Edwin 2011-02-07 09:13:24
PST ---
(In reply to comment #23)
> Appears the patch is merged in... I can disable shadows in the game and it
> looks really great...
Confirmed, latest Mesa from git works just fine.
Many
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #23 from Kevin DeKorte 2011-02-07 08:48:40
PST ---
Appears the patch is merged in... I can disable shadows in the game and it
looks really great... should I open a new bug on the shadows, or should we
continue the issue here?
--
https://bugs.freedesktop.org/show_bug.cgi?id=33348
Dawit Alemayehu changed:
What|Removed |Added
Summary|Display corruption when |[r300g] Display corruption
https://bugs.freedesktop.org/show_bug.cgi?id=33889
--- Comment #6 from Michel D?nzer 2011-02-07 07:52:45
PST ---
(In reply to comment #4)
> oh then just git master and roll it up into an RPM to confirm, will do this.
That's still not what I asked... while it'll be good to know if the bug is
> I finally did the bisect and got this as a result after a lot of rebooting:
>
> "
> 139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
> commit 139315796778a6d5f67c644e2ff470ddc69efb7b
> Author: Adam Jackson
> Date: Tue Aug 3 14:38:19 2010 -0400
<...>
> Maybe this should be
On Monday, February 07, 2011, Matthew Garrett wrote:
> On Mon, Feb 07, 2011 at 12:01:25AM +0100, Rafael J. Wysocki wrote:
>
> > Yes, it seems so, but I'm not sure what the short term consequences of that
> > change will be. Perhaps there will be none. :-)
>
> Ok, I'll have a play with that.
https://bugzilla.kernel.org/show_bug.cgi?id=21542
--- Comment #11 from curious at bwv190.internetdsl.tpnet.pl 2011-02-07 00:21:45 ---
> I finally did the bisect and got this as a result after a lot of rebooting:
>
> "
> 139315796778a6d5f67c644e2ff470ddc69efb7b is the first bad commit
>
On Sunday, February 06, 2011, Matthew Garrett wrote:
> On Sun, Feb 06, 2011 at 11:41:19PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, February 06, 2011, Matthew Garrett wrote:
> > > Ugh. Ok, how can we fix this?
> >
> > Not nicely, I'm afraid.
> >
> > One possible way is to use
drivers/gpu/drm/radeon/mkregtable.c:parser_auth() almost always remembers
to fclose(file) before returning, but it misses two spots.
This is not really important since the process will exit shortly after and
thus close the file for us, but being explicit prevents static analysis
tools from
is this a problem? before trying to submit a solution I wanted to make
sure with the experts
it seems open_count isn't locked and can cause problems
and if it is a problem, and needs to be solved, should locking be done
or is it better implemented with the (as I understand standard) kref?
Exit from drm_mode_create_tv_properties and
drm_mode_connector_update_edid_property with -ENOMEM if some of the
internal allocations fails.
This patch fixes only the mentioned routines but doesn't add handling of
the returned values to the caller side. If this patch will be accepted,
I'll also
https://bugs.freedesktop.org/show_bug.cgi?id=33889
--- Comment #6 from Michel Dänzer mic...@daenzer.net 2011-02-07 07:52:45 PST
---
(In reply to comment #4)
oh then just git master and roll it up into an RPM to confirm, will do this.
That's still not what I asked... while it'll be good to know
https://bugs.freedesktop.org/show_bug.cgi?id=33348
Dawit Alemayehu ada...@kde.org changed:
What|Removed |Added
Summary|Display corruption when |[r300g] Display
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #23 from Kevin DeKorte kdeko...@yahoo.com 2011-02-07 08:48:40 PST
---
Appears the patch is merged in... I can disable shadows in the game and it
looks really great... should I open a new bug on the shadows, or should we
continue the
https://bugs.freedesktop.org/show_bug.cgi?id=31667
--- Comment #24 from Török Edwin edwinto...@gmail.com 2011-02-07 09:13:24 PST
---
(In reply to comment #23)
Appears the patch is merged in... I can disable shadows in the game and it
looks really great...
Confirmed, latest Mesa from git
PPC Mac cards do not provide connector tables in
their vbios. Their connector/encoder configurations
must be hardcoded in the driver.
verified by nyef on #radeon
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_combios.c | 47
On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
I'm not familiar with video devices, but I agree, this situation does
feel broken. Is it the case that there's a PCI device as well as an
ACPI namespace Device for the same piece of hardware? If so, I assume
the reason for the
On Sunday, February 06, 2011 04:34:43 pm Rafael J. Wysocki wrote:
Still, IMO, there is a design issue in the entire ACPI subsystem, because the
idea of ACPI device really is not well defined, so to speak. Sometimes
they are just device interfaces that can be used to ask the firmware for
https://bugs.freedesktop.org/show_bug.cgi?id=34008
Summary: r600g: piglit failure (regression)
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
On Monday, February 07, 2011, Matthew Garrett wrote:
On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:
I'm not familiar with video devices, but I agree, this situation does
feel broken. Is it the case that there's a PCI device as well as an
ACPI namespace Device for the same
On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
is this a problem? before trying to submit a solution I wanted to make sure
with the experts
it seems open_count isn't locked and can cause problems
and if it is a problem, and needs to be solved, should locking be done or is
it
On Tue, 08 Feb 2011 08:52:52 +1000, Dave Airlie airl...@redhat.com wrote:
On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
is this a problem? before trying to submit a solution I wanted to make sure
with the experts
it seems open_count isn't locked and can cause problems
and if
https://bugzilla.kernel.org/show_bug.cgi?id=26552
Helber Maciel Guerra helbe...@gmail.com changed:
What|Removed |Added
CC|
On 02/06/2011 08:09 PM, Dave Airlie wrote:
This abstracts the pci/platform interface out a step further,
we can go further but this is far enough for now to allow USB
to be plugged in.
The drivers now just call the init code directly for their
device type.
Signed-off-by: Dave
https://bugs.freedesktop.org/show_bug.cgi?id=32350
--- Comment #34 from Edgar Villanueva evillanu...@roundbox.com 2011-02-07
19:44:26 PST ---
2.6.34.8 exhibits the same problems.
I found the kernel source for fedora 11 that worked but then I realized that I
didn't use DRM there as I had
35 matches
Mail list logo
