Jesse Barnes wrote:
> On Tue, 11 Aug 2009 20:29:39 +0200
> Thomas Hellström wrote:
>
>
>> Jesse Barnes wrote:
>>
>>> On Tue, 11 Aug 2009 11:23:09 +0200
>>> Thomas Hellström wrote:
>>>
>>>
>>>
Hi!
I'm wondering why we are using a struct device as a sysfs
repre
On Wed, Aug 12, 2009 at 11:46 AM, wrote:
> Hello Sirs/Madams:
> As we are preparing the 64bit DRM, we have tested the DRM in both case of
> 32bit user space+32bit DRM and 64bit user space + 64 bit DRM. However, we
> have a question relative to 32bit user space + 64bit DRM and request
> sugge
The calculated vdisplay was half the right value.
---
drivers/gpu/drm/drm_modes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6b4d2dc..9e54925 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/dr
Overscan, saturation, hue. Used in the nouveau driver for GPUs with
integrated TV encoders.
---
drivers/gpu/drm/drm_crtc.c | 18 ++
include/drm/drm_crtc.h |3 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/
http://bugs.freedesktop.org/show_bug.cgi?id=23234
Adam Goode changed:
What|Removed |Added
CC||a...@spicenitz.org
--- Comment #4 from A
http://bugs.freedesktop.org/show_bug.cgi?id=23240
--- Comment #2 from Stephen E. Baker 2009-08-11 17:02:15
PST ---
Today I recreated the freeze I saw this in my messages leading up to it:
Aug 11 19:35:59 goodt60 [drm] Num pipes: 1
Aug 11 19:36:05 goodt60 [drm] Num pipes: 1
Aug 11 19:36:10
On Tue, 11 Aug 2009 15:52:06 +1000
Dave Airlie wrote:
> From: Tiago Vignatti
>
> Background:
> Graphic devices are accessed through ranges in I/O or memory space.
> While most modern devices allow relocation of such ranges, some
> "Legacy" VGA devices implemented on PCI will typically have the
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Tue, 11 Aug 2009 11:23:09 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Hi!
> >>
> >> I'm wondering why we are using a struct device as a sysfs
> >> representation for connectors instead of a struct kobje
On Tue, 11 Aug 2009 16:17:46 -0700
Jesse Barnes wrote:
> On Tue, 11 Aug 2009 15:52:06 +1000
> Dave Airlie wrote:
>
> > From: Tiago Vignatti
> >
> > Background:
> > Graphic devices are accessed through ranges in I/O or memory space.
> > While most modern devices allow relocation of such ranges
http://bugs.freedesktop.org/show_bug.cgi?id=19876
Eric Anholt changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@l
http://bugs.freedesktop.org/show_bug.cgi?id=21682
Eric Anholt changed:
What|Removed |Added
Keywords||NEEDINFO
--- Comment #12 from Eric Anho
Jesse Barnes wrote:
> On Tue, 11 Aug 2009 11:23:09 +0200
> Thomas Hellström wrote:
>
>
>> Hi!
>>
>> I'm wondering why we are using a struct device as a sysfs
>> representation for connectors instead of a struct kobject?
>>
>> In particular, what stops the drm_sysfs_[suspend|resume] functions to
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström wrote:
> Hi!
>
> I'm wondering why we are using a struct device as a sysfs
> representation for connectors instead of a struct kobject?
>
> In particular, what stops the drm_sysfs_[suspend|resume] functions to
> get called for the connectors,
This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.
And clean up a small whitespace goof-up in the same function, while
I was looking at it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/driv
... by moving the assignment up.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bb59356..818c703 100644
--- a/driv
Hi all,
This series implements support for the intel overlay hw with kms.
Caveats/Remarks:
- the overlay image is flickering but stabilizes after a few secs of
showing the same frame. I've researched intel ddx history/bugs and
there was a similar issue in the original userspace modesetting dri
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most).
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this area tend to hang the hw, so let's leave it at this
for the moment. I left some dummy functions as
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/d
These will be used to ensure that the clock of pipe a is running
when the overlay is switched on. Programming logic more or less
directly ported over from userspace.
Also export the already existing helper function drm_encoder_crtc_ok.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_h
Hi,
On Tue, 2009-08-11 at 03:24 -0400, Tauseef Hussain wrote:
> Hi
> I am using a linux kernel with the following info
>
> Linux 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686
> GNU/Linux
> I would like to know what is the procedure to add new pci vendor id and
> devic
http://bugs.freedesktop.org/show_bug.cgi?id=23250
Summary: [Regression] OpenGL game is very slow with DRI2, was
fast with DRI1
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Hi!
I'm wondering why we are using a struct device as a sysfs representation
for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume] functions to
get called for the connectors, having them cast to a struct drm_minor
and sending the cpu to the bushes
Michel Dänzer wrote:
> On Tue, 2009-08-11 at 10:48 +0200, Thomas Hellström wrote:
>
>> Michel Dänzer wrote:
>>
>>> On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote:
>>>
>>>
Michel Dänzer wrote:
> On Wed, 2009-08-05 at 11:18 +0200, Thomas
On Tue, 2009-08-11 at 10:48 +0200, Thomas Hellström wrote:
> Michel Dänzer wrote:
> > On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote:
> >
> >> Michel Dänzer wrote:
> >>
> >>> On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote:
> >>>
> >>>
> Aargh. Wait. I r
Michel Dänzer wrote:
> On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote:
>
>> Michel Dänzer wrote:
>>
>>> On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote:
>>>
>>>
Aargh. Wait. I remember now.
The fbcon bo is exported through the fbdev address spa
Hi,
some minor comments below.
On Tue, 11 Aug 2009 15:52:06 +1000
Dave Airlie wrote:
> From: Tiago Vignatti
>
> Background:
> Graphic devices are accessed through ranges in I/O or memory space. While most
> modern devices allow relocation of such ranges, some "Legacy" VGA devices
> implemente
Hi
I am using a linux kernel with the following info
Linux 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686
GNU/Linux
I would like to know what is the procedure to add new pci vendor id and device
id to the list pciids.h which i found at this location ->
/usr/src/kernels
28 matches
Mail list logo
