Re: i915: GPU hang
On 30.12.2012, Guennadi Liakhovetski wrote: > Did that and it did work for a while, longer than the average with 3.5. I > was already about to write a success report, but then it hung again > yesterday. I'm not using this laptop very intensively, so, it is hard to > collect statistics. You could try to reproduce the error by writing a big file e.g. dd if=/dev/zero of=deleteme bs=1M count=8 or similar and watching high definition video on Youtube (1080p) or running a few instances of glxgears. That triggers a gpu hang in my case after just a couple of seconds. In my case, the hang doesn't occur when using SNA (or a kernel < 3.7, which isn't the case with your bug). I have this in my xorg.conf: Section "Device" Identifier "Card0" Driver "intel" Option "AccelMethod" "SNA" EndSection Without this, every 3.7 kernel produces a gpu hang within max. 1 min. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).
The patch fixes the following error seen on G5 iMac:
nouveau E[ DRM] failed to create kernel channel, -12
Reviewed-by: Michel Dänzer
Signed-off-by: Aaro Koskinen
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5614c89..69d7b1d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
if (drm->agp.stat == ENABLED) {
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = drm->agp.base;
- mem->bus.is_iomem = true;
+ mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
#endif
break;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/6] Common Display Framework-T
Hi Laurent, On Wednesday 26 of December 2012 13:14:46 Laurent Pinchart wrote: > Hi Vikas, > > On Monday 24 December 2012 12:33:50 Vikas Sajjan wrote: > > On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote: > > > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: > > >> Hi, > > >> > > >> I have been testing Common Display Framework on OMAP, and making > > >> changes that I've discussed in the posts I've sent in reply to the > > >> CDF series from Laurent. While my CDF code is rather hacky and not > > >> at all ready, I wanted to post the code for comments and also as a > > >> reference code to my posts. > > >> > > >> So here is CDF-T (Tomi-edition =). > > > > > > We've discussed your approach extensively face-to-face today so I > > > won't > > > review the patches in detail, but I will instead summarize our > > > discussion to make sure we understood each other (and let other > > > developers jump in). > > > > > > For the purpose of this discussion the term "display controller > > > driver" > > > (or just "display controller") refer to both the low-level driver > > > layer > > > that communicates directly with the display controller hardware, and > > > to > > > the higher- level driver layer that implements and exposes the > > > userspace API (FBDEV, KMS and/or V4L). Those layers can be > > > implemented in multiple kernel modules (such as in the OMAP DSS > > > case, with omapdss for the low-level layer and omapdrm, omapfb and > > > omapvout for the API-level layer) or a single kernel module. > > > > > > Control model > > > - > > > > > > The figure at > > > http://www.ideasonboard.org/media/cdf/cdf-panel-control- > > > model.png shows the CDF control model. > > > > > > The panel object depicted on the figure doesn't need to be a panel > > > in the stricter sense but could be any chain of off-SoC (both > > > on-board or off-board) display entities. It however helps thinking > > > about it as a panel and doesn't hurt the model. > > > > > > The panel is controlled through abstract control requests. Those > > > requests are used to retrieve panel information (such as the > > > physical size, the supported video modes, EDID information, ...), > > > set the panel > > > configuration (such as the active video timings) or control the > > > panel > > > operation state (enabling/disabling the panel, controlling panel > > > blanking and power management, ...). They are exposed by the panel > > > using function pointers, and called by other kernel components in > > > response to userspace requests (through the FBDEV, KMS or V4L2 > > > APIs) or in-kernel events (for instance hotplug notifications). > > > > > > In response to the control requests the panel driver will > > > communicate with the panel through the panel control bus (I2C, SPI, > > > DBI, DSI, GPIO, ..., not shown on the figure) and will control the > > > video stream it receives on its input. > > > > > > The panel is connected at the hardware level to a video source > > > (shown as a green hashed rectangle) that provides it with a video > > > stream. The video stream flows from the video source to the panel > > > and is directly controlled by its source, as shown by the green > > > arrow from the display controller to the video stream. The video > > > source exposes stream control operations as function pointers that > > > are used by the panel to control the video stream, as shown by the > > > green arrow from the panel to the video source. > > > > > > The figure at > > > http://www.ideasonboard.org/media/cdf/cdf-panel-control- > > > model-2.png shows the call flow across entities when the panel is a > > > pipeline made of more than a single entity. In this case the SoC (on > > > the left of the dashed line) outputs a video stream on a DSI bus > > > connected to a DSI to LVDS transmitter. The output of the DSI to > > > LVDS transmitter is connected to an LVDS panel (or, more > > > accurately, an LVDS panel module made of an LVDS panel controller > > > and a panel). > > > > > > The transmitter and panel module are seen by the display controller > > > and > > > userspace API implementations as a single entity that exposes > > > control > > > request operations and controls its input video stream. When a > > > control > > > request is performed (outermost green arrow) the DSI to LVDS > > > transmitter will propagate it to the panel, possibly mangling the > > > input parameters or the response. For panel operation state control > > > requests the last entity in the pipeline will likely want to > > > control the video stream it receives on its input. The video stream > > > control calls will be propagated from right to left as shown by the > > > red arrows. > > > > > > Every entity in the call stack can communicate with its hardware > > > device > > > through the corresponding control bus, and/or control the video > > > stream it receives on its input. > > > > > > This model allows filtering out modes and timings supporte
[Bug 58904] New: gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 Priority: medium Bug ID: 58904 Assignee: dri-devel@lists.freedesktop.org Summary: gloss demo broken when right clicked Severity: normal Classification: Unclassified OS: Linux (All) Reporter: smoki00...@gmail.com Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/DRI/r200 Product: Mesa Created attachment 72339 --> https://bugs.freedesktop.org/attachment.cgi?id=72339&action=edit gloss broken picture gloss demo from mesa demos When being right clicked then lose texture. Picture is in attachement. Started with 99109e9fe08f13c40ffc55e305a69e51740fc6c4 , also there with current git master. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58904] gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 smoki changed: What|Removed |Added Attachment #72339|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58904] gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 --- Comment #1 from smoki --- So it fix garbled text in that menu, but broke texture;). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58904] gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 --- Comment #2 from smoki --- tcl_mode=0 works OK, so it is again tcl case only. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43167] X intel driver causes wrong wraparound of console command line
https://bugs.freedesktop.org/show_bug.cgi?id=43167 al...@verizon.net changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Florian, Am Freitag, den 21.12.2012, 14:52 +0100 schrieb Florian Mickler: > On Tue, 18 Dec 2012 23:33:20 +0100 > Paul Menzel wrote: > > Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler: > > > > > On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote: > > > > > > > Date: Wed, 8 Aug 2012 23:12:19 +0200 > > > > > > > > Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with > > > > vertical stripes in the top half. > > > > > > This patch, which was merged in v3.6-rc4, makes the image on my ASUS > > > VW222U ca. 1 inch too wide left/right and top/bottom. The effect is as > > > if the image was zoomed (bigger, more pixely). > > > > > > Reverting it fixes the problem. > > > > I am sorry for the trouble caused by this. As a work around, you could > > also specify the QUIRKS on the Linux command line. > > > > > The Monitor is connected via VGA, but also has a DVI interface. > > > > > > Maybe the quirk-apply criteria is too unspecific? > > > > Hmm, I guess everything is identical but the DVI connector they added to > > the VW222U. Though I should have noticed the effect on the VW222S and > > did not. :( > > Hm.. why should you have noticed the effect on the VW222S? Does it > happen there too? No, it did not happen there with an Intel 915GM chip. Could you please send the `Xorg.0.log`, so that we see what you use. Maybe also a dmesg output with `dri.debug=6`. > > Could you please send the `edid-decode` output on your system and > > `/var/log/Xorg.0.log`. > > I attached the xrandr --verbose output and the > # get-edid | parse-edid > output from http://www.polypux.org/projects/read-edid/ which I already > had installed. Hope this works for you too. > > > Also I wonder how this quirk could create such a behavior. > > Yes. I'm not shure how this could happen. It probably is either a bug > somewhere, or it is the 'natural' effect of misconfiguring the vga > pipeline. Maybe someone more knowledgeable than me could make a more > educated guess about this. What should be done about this? Revert this until the reason for the regression is figured out or fix the regression? For the second option, Florian could you please create a new ticket? Thanks, Paul > > [1] http://cgit.freedesktop.org/xorg/app/edid-decode/ signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Paul, do you have a quick pointer to your decoded EDID? Maybe we can tell the VW222S and the VW222U apart. Then a small hack to the quirk-code should do the trick. Else, I'm afraid the right thing to do is to revert the quirk. I will provide the log files as soon as I'm back with that monitor, which should be next year... (Means tomorrow or the day after) Regards, Flo On Mon, 31 Dec 2012 17:37:24 +0100 Paul Menzel wrote: > Dear Florian, > > > Am Freitag, den 21.12.2012, 14:52 +0100 schrieb Florian Mickler: > > On Tue, 18 Dec 2012 23:33:20 +0100 > > Paul Menzel wrote: > > > > Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler: > > > > > > > On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote: > > > > > > > > > Date: Wed, 8 Aug 2012 23:12:19 +0200 > > > > > > > > > > Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with > > > > > vertical stripes in the top half. > > > > > > > > This patch, which was merged in v3.6-rc4, makes the image on my ASUS > > > > VW222U ca. 1 inch too wide left/right and top/bottom. The effect is as > > > > if the image was zoomed (bigger, more pixely). > > > > > > > > Reverting it fixes the problem. > > > > > > I am sorry for the trouble caused by this. As a work around, you could > > > also specify the QUIRKS on the Linux command line. > > > > > > > The Monitor is connected via VGA, but also has a DVI interface. > > > > > > > > Maybe the quirk-apply criteria is too unspecific? > > > > > > Hmm, I guess everything is identical but the DVI connector they added to > > > the VW222U. Though I should have noticed the effect on the VW222S and > > > did not. :( > > > > Hm.. why should you have noticed the effect on the VW222S? Does it > > happen there too? > > No, it did not happen there with an Intel 915GM chip. Could you please > send the `Xorg.0.log`, so that we see what you use. Maybe also a dmesg > output with `dri.debug=6`. > > > > Could you please send the `edid-decode` output on your system and > > > `/var/log/Xorg.0.log`. > > > > I attached the xrandr --verbose output and the > > # get-edid | parse-edid > > output from http://www.polypux.org/projects/read-edid/ which I already > > had installed. Hope this works for you too. > > > > > Also I wonder how this quirk could create such a behavior. > > > > Yes. I'm not shure how this could happen. It probably is either a bug > > somewhere, or it is the 'natural' effect of misconfiguring the vga > > pipeline. Maybe someone more knowledgeable than me could make a more > > educated guess about this. > > What should be done about this? Revert this until the reason for the > regression is figured out or fix the regression? For the second option, > Florian could you please create a new ticket? > > > Thanks, > > Paul > > > > > [1] http://cgit.freedesktop.org/xorg/app/edid-decode/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58914] New: Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID
https://bugs.freedesktop.org/show_bug.cgi?id=58914 Priority: medium Bug ID: 58914 Assignee: dri-devel@lists.freedesktop.org Summary: Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: david.hag...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 72358 --> https://bugs.freedesktop.org/attachment.cgi?id=72358&action=edit X Start up log messages The Radeon driver will not load with the Radeon kernel drivers in Linux 3.8.0 The following is an excerpt from the startup: [ 109.112] (II) Loading extension DRI2 [ 109.112] (II) LoadModule: "radeon" [ 109.112] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 109.112] (II) Module radeon: vendor="X.Org Foundation" [ 109.112]compiled for 1.12.3, module version = 7.0.99 [ 109.112]Module class: X.Org Video Driver [ 109.112]ABI class: X.Org Video Driver, version 12.0 [ 109.112] (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), (many cards snipped) [ 109.114] (--) using VT number 8 [ 109.119] (II) [KMS] Kernel modesetting enabled. [ 109.120] (II) RADEON(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 109.120] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 109.120] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 109.120] (==) RADEON(0): Default visual is TrueColor [ 109.120] (==) RADEON(0): RGB weight 888 [ 109.120] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 109.120] (--) RADEON(0): Chipset: "ATI Radeon HD 4350" (ChipID = 0x954f) [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: Searching for BusID pci::04:00.0 [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: drmOpenMinor returns 9 [ 109.120] drmOpenByBusid: Searching for BusID pci::04:00.0 [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: drmOpenMinor returns 9 [ 109.120] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 109.120] drmOpenByBusid: drmGetBusid reports That last line is not a copy/paste issue - it literally is "[ 109.120] drmOpenByBusid: drmGetBusid reports " (as in, there is no bus ID given) Then the X Radeon driver looks for any other DRI node, fails, and dies. [ 109.120] drmOpenDevice: node name is /dev/dri/card1 [ 109.125] drmOpenByBusid: drmOpenMinor returns -1 (snip many other searches) [ 109.170] drmOpenDevice: node name is /dev/dri/card14 [ 109.174] drmOpenByBusid: drmOpenMinor returns -1 [ 109.174] drmOpenDevice: node name is /dev/dri/card15 [ 109.178] drmOpenByBusid: drmOpenMinor returns -1 [ 109.178] drmOpenDevice: node name is /dev/dri/card0 [ 109.178] drmOpenDevice: open result is 9, (OK) [ 109.178] drmOpenDevice: node name is /dev/dri/card0 [ 109.178] drmOpenDevice: open result is 9, (OK) [ 109.178] drmGetBusid returned '' [ 109.178] (EE) RADEON(0): [drm] failed to set drm interface version. [ 109.178] (EE) RADEON(0): Kernel modesetting setup failed [ 109.178] (II) UnloadModule: "radeon" [ 109.178] (EE) Screen(s) found, but none have a usable configuration. I have tried the following: 1) adding the following parameters in /etc/modprobe.d/radeon.conf options radeon modeset=1 dynclks=1 gartsize=256 audio=1 pcie_gen2=-1 msi=1 2) Adding the following to /etc/initramfs-tools/modules radeon modeset=1 dynclks=1 gartsize=256 audio=1 pcie_gen2=-1 msi=1 and rebuilding the ramdisk. The kernel has the following configuration with respect to the Radeon drivers: CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y # CONFIG_FB_RADEON is not set -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
On Mon, Dec 31, 2012 at 03:34:59AM +0200, Aaro Koskinen wrote:
> Check that the AGP aperture can be mapped. This follows a similar change
> done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
> the aperture can be mapped by the CPU.).
>
> The patch fixes the following error seen on G5 iMac:
>
> nouveau E[ DRM] failed to create kernel channel, -12
>
> Reviewed-by: Michel Dänzer
> Signed-off-by: Aaro Koskinen
> ---
This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=58806.
For some (weird) reason Nouveau worked on this configuration on 3.6 kernel,
so cc'ing stable@vger seems to be appropriate.
> drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 5614c89..69d7b1d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
> struct ttm_mem_reg *mem)
> if (drm->agp.stat == ENABLED) {
> mem->bus.offset = mem->start << PAGE_SHIFT;
> mem->bus.base = drm->agp.base;
> - mem->bus.is_iomem = true;
> + mem->bus.is_iomem = !dev->agp->cant_use_aperture;
> }
> #endif
> break;
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 Anthony Waters changed: What|Removed |Added CC||cuu...@gmail.com --- Comment #25 from Anthony Waters --- *** Bug 42854 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Florian, first, I wish everyone a Happy New Year! Am Montag, den 31.12.2012, 18:22 +0100 schrieb Florian Mickler: > do you have a quick pointer to your decoded EDID? yes, everything is in the bug report the patch was supposed to fix [1]. > Maybe we can tell the VW222S and the VW222U apart. Then a small hack > to the quirk-code should do the trick. The EDID luckily is different. $ diff -u asus-vw222s.edid asus-vw222u.edid --- asus-vw222s.edid2012-08-15 17:22:32.172213340 +0200 +++ asus-vw222u.edid2013-01-01 04:33:45.271951086 +0100 @@ -1,8 +1,8 @@ -00000469a22201010101 -0c1201031e2f1e78eec4f6a3574a9c23 +00000469a222a618 +2e1101031e2f1e78eec4f6a3574a9c23 114f54bfef00714f818081409500a940 b3000101010121399030621a274068b0 3600d928111c00fd00384b1f 5111000a20202020202000fc0056 573232320a2020202020202000ff -0038334c4d51533037393235300a00b3 +0037424c4d51433030363331302000d1 Here the strings output by `edid-decode`. ### VW222S ### $ ./edid-decode asus-vw222s.edid […] Manufacturer: ACI Model 22a2 Serial Number 16843009 Made week 12 of 2008 EDID version: 1.3 Analog display, Input voltage level: 0.7/0.3 V Configurable signal levels Sync: Separate Composite SyncOnGreen Maximum image size: 47 cm x 30 cm Gamma: 2.20 DPMS levels: Standby Suspend Off RGB color display Default (sRGB) color space is primary color space First detailed timing is preferred timing Established timings supported: 720x400@70Hz 640x480@60Hz 640x480@67Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 832x624@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz Standard timings supported: 1152x864@75Hz 1280x1024@60Hz 1280x960@60Hz 1440x900@60Hz 1600x1200@60Hz 1680x1050@60Hz Detailed mode: Clock 146.250 MHz, 473 mm x 296 mm 1680 1784 1960 2240 hborder 0 1050 1053 1059 1089 vborder 0 -hsync +vsync Monitor ranges (GTF): 56-75Hz V, 31-81kHz H, max dotclock 170MHz Monitor name: VW222 Serial number: 83LMQS079250 Checksum: 0xb3 (valid) ### VW222U ### $ ./edid-decode asus-vw222u.edid […] Manufacturer: ACI Model 22a2 Serial Number 6310 Made week 46 of 2007 EDID version: 1.3 Analog display, Input voltage level: 0.7/0.3 V Configurable signal levels Sync: Separate Composite SyncOnGreen Maximum image size: 47 cm x 30 cm Gamma: 2.20 DPMS levels: Standby Suspend Off RGB color display Default (sRGB) color space is primary color space First detailed timing is preferred timing Established timings supported: 720x400@70Hz 640x480@60Hz 640x480@67Hz 640x480@72Hz 640x480@75Hz 800x600@56Hz 800x600@60Hz 800x600@72Hz 800x600@75Hz 832x624@75Hz 1024x768@60Hz 1024x768@70Hz 1024x768@75Hz 1280x1024@75Hz Standard timings supported: 1152x864@75Hz 1280x1024@60Hz 1280x960@60Hz 1440x900@60Hz 1600x1200@60Hz 1680x1050@60Hz Detailed mode: Clock 146.250 MHz, 473 mm x 296 mm 1680 1784 1960 2240 hborder 0 1050 1053 1059 1089 vborder 0 -hsync +vsync Monitor ranges (GTF): 56-75Hz V, 31-81kHz H, max dotclock 170MHz Monitor name: VW222 Serial number: 7BLMQC006310 Checksum: 0xd1 (valid) So both advertise the same name and model. :( > Else, I'm afraid the right thing to do is to revert the quirk. Yes, the no regression rule. > I will provide the log files as soon as I'm back with that monitor, > which should be next year... (Means tomorrow or the day after) Awesome. When you find out the graphics chip and you are near the monitor it would be awesome, if you could also connect a to a system with a different graphics chip so we can get an indication where the problem might be. So if nobody has a great idea, the roadmap looks as follows. Revert the patch, find out why the graphics driver chokes on the reduced blanking (report a bug) and commit the patch again. Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=17629#c15 signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.o
[RFC,libdrm 1/3] tegra: Add stream library
On 28.12.2012 22:48, Thierry Reding wrote: > I disagree. We shouldn't be hiding this kind of detail behind an #ifdef. > Instead it should be detected at runtime. Otherwise you'll need to build > different versions of libdrm for every generation of Tegra. That may be > fine for NVIDIA provided BSPs, but distributions would have a very hard > time dealing with that. What we want is software that works unmodified > on as many generations of Tegra as possible. I agree. The fences will be rejected by kernel and kernel knows about number of sync points in each host1x revision. So, we could just submit and look at return code. Terje
[PATCHv4 5/8] drm: tegra: Remove redundant host1x
On 28.12.2012 23:21, Thierry Reding wrote: > Instead of going over this back and forth, I've decided to rewrite this > patch from scratch the way I think it should be done. Maybe that'll make > things clearer. I haven't tested it on real hardware yet because I don't > have access over the holidays, but I'll post the patch once I've > verified that it actually works. The code is based on patches 1-4 of > this series and is meant to replace patch 5. I'm still not happy that host1x needs to know about drm. That's just a wrong dependency, and wrong dependencies always end up biting back. We need to figure out solution that satisfies both mine and your requirements and reduce complexity. DC/HDMI/GR2D probes are using the global data only for managing the lists "drm_clients" and "clients". "clients" list is only required after tegra_drm_load(). "drm_clients" is required to establish driver load order. With dummy device, we can determine the registration (and probe) order. tegra-drm can register the drivers for DC/HDMI/GR2D devices first, and as last the device and driver for tegra-drm. tegra-drm probe will allocate the global data, enumerate all drivers and add them to the clients list. If one driver is not initialized, it'll return with -EPROBE_DEFER and will be called again later. When all this is successful, it'll call drm_platform_init(). The advantages: * No management of drm_clients list * No mucking with drvdata * host1x doesn't need to know about drm * The global data is allocated and deallocated by tegra-drm probe and remove, and accessed only via drm_device->dev_private * Much less code Something like the attached patch - not tested, as I don't have access to hw now, but it shows the idea. It's based on patches 1-5 in the series, and could replace patch 5. Terje -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-tegra-Postpone-usage-of-global-data.patch Type: text/x-patch Size: 11602 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/dc1e9565/attachment-0001.bin>
[RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth
Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).
The patch fixes the following error seen on G5 iMac:
nouveau E[ DRM] failed to create kernel channel, -12
Reviewed-by: Michel D?nzer
Signed-off-by: Aaro Koskinen
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5614c89..69d7b1d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *mem)
if (drm->agp.stat == ENABLED) {
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = drm->agp.base;
- mem->bus.is_iomem = true;
+ mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
#endif
break;
--
1.7.10.4
[RFC 0/6] Common Display Framework-T
Hi Laurent, On Wednesday 26 of December 2012 13:14:46 Laurent Pinchart wrote: > Hi Vikas, > > On Monday 24 December 2012 12:33:50 Vikas Sajjan wrote: > > On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart wrote: > > > On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote: > > >> Hi, > > >> > > >> I have been testing Common Display Framework on OMAP, and making > > >> changes that I've discussed in the posts I've sent in reply to the > > >> CDF series from Laurent. While my CDF code is rather hacky and not > > >> at all ready, I wanted to post the code for comments and also as a > > >> reference code to my posts. > > >> > > >> So here is CDF-T (Tomi-edition =). > > > > > > We've discussed your approach extensively face-to-face today so I > > > won't > > > review the patches in detail, but I will instead summarize our > > > discussion to make sure we understood each other (and let other > > > developers jump in). > > > > > > For the purpose of this discussion the term "display controller > > > driver" > > > (or just "display controller") refer to both the low-level driver > > > layer > > > that communicates directly with the display controller hardware, and > > > to > > > the higher- level driver layer that implements and exposes the > > > userspace API (FBDEV, KMS and/or V4L). Those layers can be > > > implemented in multiple kernel modules (such as in the OMAP DSS > > > case, with omapdss for the low-level layer and omapdrm, omapfb and > > > omapvout for the API-level layer) or a single kernel module. > > > > > > Control model > > > - > > > > > > The figure at > > > http://www.ideasonboard.org/media/cdf/cdf-panel-control- > > > model.png shows the CDF control model. > > > > > > The panel object depicted on the figure doesn't need to be a panel > > > in the stricter sense but could be any chain of off-SoC (both > > > on-board or off-board) display entities. It however helps thinking > > > about it as a panel and doesn't hurt the model. > > > > > > The panel is controlled through abstract control requests. Those > > > requests are used to retrieve panel information (such as the > > > physical size, the supported video modes, EDID information, ...), > > > set the panel > > > configuration (such as the active video timings) or control the > > > panel > > > operation state (enabling/disabling the panel, controlling panel > > > blanking and power management, ...). They are exposed by the panel > > > using function pointers, and called by other kernel components in > > > response to userspace requests (through the FBDEV, KMS or V4L2 > > > APIs) or in-kernel events (for instance hotplug notifications). > > > > > > In response to the control requests the panel driver will > > > communicate with the panel through the panel control bus (I2C, SPI, > > > DBI, DSI, GPIO, ..., not shown on the figure) and will control the > > > video stream it receives on its input. > > > > > > The panel is connected at the hardware level to a video source > > > (shown as a green hashed rectangle) that provides it with a video > > > stream. The video stream flows from the video source to the panel > > > and is directly controlled by its source, as shown by the green > > > arrow from the display controller to the video stream. The video > > > source exposes stream control operations as function pointers that > > > are used by the panel to control the video stream, as shown by the > > > green arrow from the panel to the video source. > > > > > > The figure at > > > http://www.ideasonboard.org/media/cdf/cdf-panel-control- > > > model-2.png shows the call flow across entities when the panel is a > > > pipeline made of more than a single entity. In this case the SoC (on > > > the left of the dashed line) outputs a video stream on a DSI bus > > > connected to a DSI to LVDS transmitter. The output of the DSI to > > > LVDS transmitter is connected to an LVDS panel (or, more > > > accurately, an LVDS panel module made of an LVDS panel controller > > > and a panel). > > > > > > The transmitter and panel module are seen by the display controller > > > and > > > userspace API implementations as a single entity that exposes > > > control > > > request operations and controls its input video stream. When a > > > control > > > request is performed (outermost green arrow) the DSI to LVDS > > > transmitter will propagate it to the panel, possibly mangling the > > > input parameters or the response. For panel operation state control > > > requests the last entity in the pipeline will likely want to > > > control the video stream it receives on its input. The video stream > > > control calls will be propagated from right to left as shown by the > > > red arrows. > > > > > > Every entity in the call stack can communicate with its hardware > > > device > > > through the corresponding control bus, and/or control the video > > > stream it receives on its input. > > > > > > This model allows filtering out modes and timings supporte
[Bug 58904] New: gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 Priority: medium Bug ID: 58904 Assignee: dri-devel at lists.freedesktop.org Summary: gloss demo broken when right clicked Severity: normal Classification: Unclassified OS: Linux (All) Reporter: smoki00790 at gmail.com Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/DRI/r200 Product: Mesa Created attachment 72339 --> https://bugs.freedesktop.org/attachment.cgi?id=72339&action=edit gloss broken picture gloss demo from mesa demos When being right clicked then lose texture. Picture is in attachement. Started with 99109e9fe08f13c40ffc55e305a69e51740fc6c4 , also there with current git master. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/faa728d9/attachment.html>
[Bug 58904] gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 smoki changed: What|Removed |Added Attachment #72339|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/63287c27/attachment-0001.html>
[Bug 58904] gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 --- Comment #1 from smoki --- So it fix garbled text in that menu, but broke texture;). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/2a12bf18/attachment.html>
[Bug 58904] gloss demo broken when right clicked
https://bugs.freedesktop.org/show_bug.cgi?id=58904 --- Comment #2 from smoki --- tcl_mode=0 works OK, so it is again tcl case only. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/a7acc5eb/attachment.html>
[Bug 43167] X intel driver causes wrong wraparound of console command line
https://bugs.freedesktop.org/show_bug.cgi?id=43167 alupu at verizon.net changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/faf064af/attachment.html>
[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Florian, Am Freitag, den 21.12.2012, 14:52 +0100 schrieb Florian Mickler: > On Tue, 18 Dec 2012 23:33:20 +0100 > Paul Menzel wrote: > > Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler: > > > > > On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote: > > > > > > > Date: Wed, 8 Aug 2012 23:12:19 +0200 > > > > > > > > Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with > > > > vertical stripes in the top half. > > > > > > This patch, which was merged in v3.6-rc4, makes the image on my ASUS > > > VW222U ca. 1 inch too wide left/right and top/bottom. The effect is as > > > if the image was zoomed (bigger, more pixely). > > > > > > Reverting it fixes the problem. > > > > I am sorry for the trouble caused by this. As a work around, you could > > also specify the QUIRKS on the Linux command line. > > > > > The Monitor is connected via VGA, but also has a DVI interface. > > > > > > Maybe the quirk-apply criteria is too unspecific? > > > > Hmm, I guess everything is identical but the DVI connector they added to > > the VW222U. Though I should have noticed the effect on the VW222S and > > did not. :( > > Hm.. why should you have noticed the effect on the VW222S? Does it > happen there too? No, it did not happen there with an Intel 915GM chip. Could you please send the `Xorg.0.log`, so that we see what you use. Maybe also a dmesg output with `dri.debug=6`. > > Could you please send the `edid-decode` output on your system and > > `/var/log/Xorg.0.log`. > > I attached the xrandr --verbose output and the > # get-edid | parse-edid > output from http://www.polypux.org/projects/read-edid/ which I already > had installed. Hope this works for you too. > > > Also I wonder how this quirk could create such a behavior. > > Yes. I'm not shure how this could happen. It probably is either a bug > somewhere, or it is the 'natural' effect of misconfiguring the vga > pipeline. Maybe someone more knowledgeable than me could make a more > educated guess about this. What should be done about this? Revert this until the reason for the regression is figured out or fix the regression? For the second option, Florian could you please create a new ticket? Thanks, Paul > > [1] http://cgit.freedesktop.org/xorg/app/edid-decode/ -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/5c726f0b/attachment.pgp>
[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
Dear Paul, do you have a quick pointer to your decoded EDID? Maybe we can tell the VW222S and the VW222U apart. Then a small hack to the quirk-code should do the trick. Else, I'm afraid the right thing to do is to revert the quirk. I will provide the log files as soon as I'm back with that monitor, which should be next year... (Means tomorrow or the day after) Regards, Flo On Mon, 31 Dec 2012 17:37:24 +0100 Paul Menzel wrote: > Dear Florian, > > > Am Freitag, den 21.12.2012, 14:52 +0100 schrieb Florian Mickler: > > On Tue, 18 Dec 2012 23:33:20 +0100 > > Paul Menzel wrote: > > > > Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler: > > > > > > > On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote: > > > > > > > > > Date: Wed, 8 Aug 2012 23:12:19 +0200 > > > > > > > > > > Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with > > > > > vertical stripes in the top half. > > > > > > > > This patch, which was merged in v3.6-rc4, makes the image on my ASUS > > > > VW222U ca. 1 inch too wide left/right and top/bottom. The effect is as > > > > if the image was zoomed (bigger, more pixely). > > > > > > > > Reverting it fixes the problem. > > > > > > I am sorry for the trouble caused by this. As a work around, you could > > > also specify the QUIRKS on the Linux command line. > > > > > > > The Monitor is connected via VGA, but also has a DVI interface. > > > > > > > > Maybe the quirk-apply criteria is too unspecific? > > > > > > Hmm, I guess everything is identical but the DVI connector they added to > > > the VW222U. Though I should have noticed the effect on the VW222S and > > > did not. :( > > > > Hm.. why should you have noticed the effect on the VW222S? Does it > > happen there too? > > No, it did not happen there with an Intel 915GM chip. Could you please > send the `Xorg.0.log`, so that we see what you use. Maybe also a dmesg > output with `dri.debug=6`. > > > > Could you please send the `edid-decode` output on your system and > > > `/var/log/Xorg.0.log`. > > > > I attached the xrandr --verbose output and the > > # get-edid | parse-edid > > output from http://www.polypux.org/projects/read-edid/ which I already > > had installed. Hope this works for you too. > > > > > Also I wonder how this quirk could create such a behavior. > > > > Yes. I'm not shure how this could happen. It probably is either a bug > > somewhere, or it is the 'natural' effect of misconfiguring the vga > > pipeline. Maybe someone more knowledgeable than me could make a more > > educated guess about this. > > What should be done about this? Revert this until the reason for the > regression is figured out or fix the regression? For the second option, > Florian could you please create a new ticket? > > > Thanks, > > Paul > > > > > [1] http://cgit.freedesktop.org/xorg/app/edid-decode/
[Bug 58914] New: Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID
https://bugs.freedesktop.org/show_bug.cgi?id=58914 Priority: medium Bug ID: 58914 Assignee: dri-devel at lists.freedesktop.org Summary: Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: david.hagood at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 72358 --> https://bugs.freedesktop.org/attachment.cgi?id=72358&action=edit X Start up log messages The Radeon driver will not load with the Radeon kernel drivers in Linux 3.8.0 The following is an excerpt from the startup: [ 109.112] (II) Loading extension DRI2 [ 109.112] (II) LoadModule: "radeon" [ 109.112] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 109.112] (II) Module radeon: vendor="X.Org Foundation" [ 109.112]compiled for 1.12.3, module version = 7.0.99 [ 109.112]Module class: X.Org Video Driver [ 109.112]ABI class: X.Org Video Driver, version 12.0 [ 109.112] (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), (many cards snipped) [ 109.114] (--) using VT number 8 [ 109.119] (II) [KMS] Kernel modesetting enabled. [ 109.120] (II) RADEON(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 109.120] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 109.120] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 109.120] (==) RADEON(0): Default visual is TrueColor [ 109.120] (==) RADEON(0): RGB weight 888 [ 109.120] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 109.120] (--) RADEON(0): Chipset: "ATI Radeon HD 4350" (ChipID = 0x954f) [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: Searching for BusID pci::04:00.0 [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: drmOpenMinor returns 9 [ 109.120] drmOpenByBusid: Searching for BusID pci::04:00.0 [ 109.120] drmOpenDevice: node name is /dev/dri/card0 [ 109.120] drmOpenDevice: open result is 9, (OK) [ 109.120] drmOpenByBusid: drmOpenMinor returns 9 [ 109.120] drmOpenByBusid: Interface 1.4 failed, trying 1.1 [ 109.120] drmOpenByBusid: drmGetBusid reports That last line is not a copy/paste issue - it literally is "[ 109.120] drmOpenByBusid: drmGetBusid reports " (as in, there is no bus ID given) Then the X Radeon driver looks for any other DRI node, fails, and dies. [ 109.120] drmOpenDevice: node name is /dev/dri/card1 [ 109.125] drmOpenByBusid: drmOpenMinor returns -1 (snip many other searches) [ 109.170] drmOpenDevice: node name is /dev/dri/card14 [ 109.174] drmOpenByBusid: drmOpenMinor returns -1 [ 109.174] drmOpenDevice: node name is /dev/dri/card15 [ 109.178] drmOpenByBusid: drmOpenMinor returns -1 [ 109.178] drmOpenDevice: node name is /dev/dri/card0 [ 109.178] drmOpenDevice: open result is 9, (OK) [ 109.178] drmOpenDevice: node name is /dev/dri/card0 [ 109.178] drmOpenDevice: open result is 9, (OK) [ 109.178] drmGetBusid returned '' [ 109.178] (EE) RADEON(0): [drm] failed to set drm interface version. [ 109.178] (EE) RADEON(0): Kernel modesetting setup failed [ 109.178] (II) UnloadModule: "radeon" [ 109.178] (EE) Screen(s) found, but none have a usable configuration. I have tried the following: 1) adding the following parameters in /etc/modprobe.d/radeon.conf options radeon modeset=1 dynclks=1 gartsize=256 audio=1 pcie_gen2=-1 msi=1 2) Adding the following to /etc/initramfs-tools/modules radeon modeset=1 dynclks=1 gartsize=256 audio=1 pcie_gen2=-1 msi=1 and rebuilding the ramdisk. The kernel has the following configuration with respect to the Radeon drivers: CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y # CONFIG_FB_RADEON is not set -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121231/9d29586b/attachment.html>
