Re: [Intel-gfx] [Resend2] [PATCH 0/3] Add the default mode for LVDS in KMS mode
On Mon, 2009-06-08 at 10:04 +0800, yakui_zhao wrote: > Hi, All > the following is the patch set that adds the default modes for LVDS in > KMS > mode. It is to solve the following bugs: > http://bugs.freedesktop.org/show_bug.cgi?id=20801 > http://bugs.freedesktop.org/show_bug.cgi?id=21094 > http://bugs.freedesktop.org/show_bug.cgi?id=21346 > http://bugs.freedesktop.org/show_bug.cgi?id=21417 > http://bugs.freedesktop.org/show_bug.cgi?id=21671 > HI, Carl How about this patch set? Without this patch, the xrandr will get less modes for LVDS device than UMS mode. Now it seems that this is the KMS gap. thanks. Yakui > > Patch 1/3: Add a private data for LVDS > When the connector type is LVDS, it will add a private data > that > can be used to store the LVDS panel limit. For example: hdisplay, vdisplay. > > Patch 2/3: Get the LVDS panel limit and check whether the given modeline > is valid > Traverse the mode list returned by KMS kernel to get the LVDS > panel > limit. And the panel limit is used to check whether the given modeline is > valid. > > Patch 3/3: Add the default modes for the LVDS > This is similar to what we have done in UMS mode > a. When there exists the EDID, either find a DS_RANGES > block or replace a DS_VENDOR block , smashing it into a DS_RANGES block > with open refresh to match all the default modes. > b. When there is no EDID, we will construct a bogus EDID > and add a DS_RANGES block with open refresh to match all the default > modes > > welcome the comments. > > Best regards > Yakui > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch 0/5] [DRM/I915] :Separate several DRM debug levels
On Tue, 2009-06-02 at 14:07 +0800, yakui_zhao wrote: > Hi, Hi, Any comments on this patch set? Is it convenient to get the debug info in KMS mode? Thanks. > When the X is started in UMS mode, we can see the info related with the > mode > setting in the Xorg.log(For example: SDVO device command, modeline > validation). > This is very helpful to analyze the issue related with modesetting. > When KMS is used, we have no such info. Maybe it is very useful that > we can get such info in KMS mode. For example: adding the debug info by > using the DRM_DEBUG macro definition. > > Now all the DRM debug info will be reported if the boot option of > "drm.debug=1" is added. Sometimes it is inconvenient to get the debug > info in KMS mode. We will get too much unrelated info. For example: drm > ioctl info. > > The following patch set is to add several different debug level for > DRM. The debug level can be used to print the different debug info.For > example: The DRM_CORE level can be used to print the debug info related > with drm ioctl. The debug level is controlled by the drm_debug module > parameter. It can be changed by adding the boot option or drm module > parameter I/F. > > > Patch 1/5: Separate the different DRM debug levels. > In the patch four debug levels are defined. DRM_CORE, > DRIVER, KMS, MODE > Patch 2/5: Replace the DRM_DEBUG with DRM_DEBUG_KMS to print the > info in intel_lvds > > Patch 3/5: Replace the DrM_DEBUG with DRM_DEBUG_KMS to print the > debug info in intel_sdvo > > Patch 4/5: Replace the DRM_DEBUG with DRM_DEBUG_MODE to print the > debug info in drm_mode > > Patch 5/5: Replace the DRM_DEBUG with DRM_DEBUG_DRIVER to print the > debug info in i915 driver. > > Welcome the comments. > > Thanks. > > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Resend] [PATCH 0/3] use the sdvo device info parsed from VBT to initialize SDVO device
On Mon, 2009-06-08 at 10:18 +0800, yakui_zhao wrote: > Hi, Hi, Carl How about this patch set? I also send the KMS version of patch set for this issue. And this patch set is already shipped. Thanks. Yakui > The following is the patch set that use the SDVO device info > parsed from general definition block to initialize the SDVO device. > It is to fix the following bug: > http://bugs.freedesktop.org/show_bug.cgi?id=20429 > > By parsing the general definition block of VBT we can get the > relationship between the DVO port and slave address. For example: the > SDVO wiring, the SDVO slave address. And then we use the info to > initialize the SDVO device. If the slave address can obtained for SDVO > port(SDVOB/SDVOC), it will be initialized correctly. If no slave address > is found in the SDVO device info parsed from VBT, it will return the slave > address > by using the following flowchart: > a. If the SDVO device info is found for another SDVO port, it will > return the slave address that is not used. For example: if 0x70 is used, then > 0x72 is returned. If 0x72 is used, 0x70 is returned. > b. If no SDVO device info is found for another SDVO port, it will > return 0x70 for SDVOB and 0x72 for SDVOC. > > Patch 01/3: Dynamically get the number of child device in general > definition block > Patch 02/3: parse general definition block to get the SDVO > device info. > Patch 03/3: Initialize the SDVO device based on the the sdvo > device info parsed from general definition block > > Welcome the comments. > > Yakui > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Resend2] [PATCH 0/3] Add the default mode for LVDS in KMS mode
On Mon, 2009-06-08 at 10:04 +0800, yakui_zhao wrote: > Hi, All > the following is the patch set that adds the default modes for LVDS in > KMS > mode. It is to solve the following bugs: > http://bugs.freedesktop.org/show_bug.cgi?id=20801 > http://bugs.freedesktop.org/show_bug.cgi?id=21094 > http://bugs.freedesktop.org/show_bug.cgi?id=21346 > http://bugs.freedesktop.org/show_bug.cgi?id=21417 > http://bugs.freedesktop.org/show_bug.cgi?id=21671 > Hi, Jessa/Eric How about this patch set? In this patch set the default modes are added in user space. At the same time I also use the LVDS panel limit to check whether the modeline is valid.The modeline added by xrandr tool can also be validated. Will you please review the patch set? Is something missing in my patch set? Now it seems that this is the KMS gap. Xrandr tool will get less modes for LVDS output device than KMS mode. Thanks. > > Patch 1/3: Add a private data for LVDS > When the connector type is LVDS, it will add a private data > that > can be used to store the LVDS panel limit. For example: hdisplay, vdisplay. > > Patch 2/3: Get the LVDS panel limit and check whether the given modeline > is valid > Traverse the mode list returned by KMS kernel to get the LVDS > panel > limit. And the panel limit is used to check whether the given modeline is > valid. > > Patch 3/3: Add the default modes for the LVDS > This is similar to what we have done in UMS mode > a. When there exists the EDID, either find a DS_RANGES > block or replace a DS_VENDOR block , smashing it into a DS_RANGES block > with open refresh to match all the default modes. > b. When there is no EDID, we will construct a bogus EDID > and add a DS_RANGES block with open refresh to match all the default > modes > > welcome the comments. > > Best regards > Yakui > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Plumbers Conference X Window System track submissions
On Mon, 2009-06-08 at 22:26 -0700, Corbin Simpson wrote: > As somebody who can't keep his mouth shut, would any of the following be > interesting/"Oh hey, you'll talk about it? Then I don't have to!": I'm supposed to be emceeing this event, not doing a solo... > - omapfb, DSS/DSS2, and why embedded is painful Some discussion on how Linux graphics should work in embedded computing would be really useful; I know I've been focusing a lot on desktop stuff and not paying much attention to smaller boxes for several years now. I miss my tiny toys... > - State of Gallium3D In general, Plumbers isn't a great venue for 'state of ' talks; it's an intimate conference which is designed to allow for significant interaction between the participants. If there are particular details about Gallium3D which could benefit from feedback, then I'd say that would probably be a better offering. > - Shatter (that GSoC thingy I need to put more work into) Yeah, we need to make sure Shatter happens, so getting feedback from a wide range of developers over how it should work might prove extremely valuable. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Plumbers Conference X Window System track submissions
Keith Packard wrote: > Paul McKenney reminds me that submissions for the X track at Plumbers > are due shortly (Monday, 15 June 2009 PDT); I'd love to hear from anyone > interested in helping with a presentation or other content for our slot. > > I'm interested in hearing about presentations, demonstrations and topics > for discussion with the group. We had a great session last year, let's > see if we can't do even better this year. > > Please let me know before the deadline if you have something to propose. > > http://linuxplumbersconf.org/ocw/events/2009/proposals/ > > Conference details: > > Linux Plumbers Conference > Portland, Oregon > 23-25 Sept 2009 As somebody who can't keep his mouth shut, would any of the following be interesting/"Oh hey, you'll talk about it? Then I don't have to!": - omapfb, DSS/DSS2, and why embedded is painful - State of Gallium3D - Shatter (that GSoC thingy I need to put more work into) ~ C. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Plumbers Conference X Window System track submissions
Paul McKenney reminds me that submissions for the X track at Plumbers are due shortly (Monday, 15 June 2009 PDT); I'd love to hear from anyone interested in helping with a presentation or other content for our slot. I'm interested in hearing about presentations, demonstrations and topics for discussion with the group. We had a great session last year, let's see if we can't do even better this year. Please let me know before the deadline if you have something to propose. http://linuxplumbersconf.org/ocw/events/2009/proposals/ Conference details: Linux Plumbers Conference Portland, Oregon 23-25 Sept 2009 -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22167] New: [855GM] corrupted fonts with xf86-video-intel from git
http://bugs.freedesktop.org/show_bug.cgi?id=22167 Summary: [855GM] corrupted fonts with xf86-video-intel from git Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: vmik...@frugalware.org Hi, I upgraded to "X.Org X Server 1.6.1" recently and first I noticed that the updated xf86-video-intel 2.7.1 had a totally screwed up output. I could not make a screenshot of it, basically there were some output (ie it was not a black screen), but it was unreadable. Then I updated xf86-video-intel to latest git (commit 66ceedc) and I got an other type of corruption: the picture is almost OK, but the some fonts are unreadable: http://frugalware.org/~vmiklos/logs/xf86-video-intel/xf86-video-intel-66ceedc.png The weird thing is that after this, I downgraded xf86-video-intel back to 2.7.1 and everything was fine: http://frugalware.org/~vmiklos/logs/xf86-video-intel/xf86-video-intel-2.7.1.png ... till I rebooted. So I can reproduce this: after reboot 2.7.1 is broken, upgrading to git is not working either, but after this when I downgrade everything is fine again. Anytime I put Option "NoAccel" "false" to xorg.conf, both drivers are okay. System info: lspci output: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) kernel: 2.6.29.3, i686 distro: Frugalware Linux 1.1pre1 xserver 1.6.1-7, mesa 7.4.2, libdrm 2.4.11 The notebook is a Clevo M450C. xorg.conf: http://frugalware.org/~vmiklos/logs/xf86-video-intel/xorg.conf Xorg.0.log for both driver versions: http://frugalware.org/~vmiklos/logs/xf86-video-intel/xf86-video-intel-2.7.1.log http://frugalware.org/~vmiklos/logs/xf86-video-intel/xf86-video-intel-66ceedc.log dmesg: http://frugalware.org/~vmiklos/logs/xf86-video-intel/dmesg Let me know if I missed any required info. :) Thanks! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22146] to cherry-pick DRI2 frontbuffer rendering fix to mesa 7_5 branch
http://bugs.freedesktop.org/show_bug.cgi?id=22146 Gordon Jin changed: What|Removed |Added AssignedTo|dri-|i...@freedesktop.org |de...@lists.sourceforge.net | Severity|normal |critical Priority|medium |high Summary|DRI2 frontbuffer rendering |to cherry-pick DRI2 |broken on mesa 7_5 branch, |frontbuffer rendering fix to |but works on master |mesa 7_5 branch -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13490] after some time of inactivity display turns black - requires hard restart
http://bugzilla.kernel.org/show_bug.cgi?id=13490 Ben Gamari changed: What|Removed |Added CC||bgam...@gmail.com --- Comment #1 from Ben Gamari 2009-06-08 21:14:31 --- I am seeing this as well on GM965. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22164] New: PATCH: Fix DRM_MAJOR for NetBSD in libdrm
http://bugs.freedesktop.org/show_bug.cgi?id=22164 Summary: PATCH: Fix DRM_MAJOR for NetBSD in libdrm Product: DRI Version: XOrg CVS Platform: All OS/Version: NetBSD Status: NEW Severity: major Priority: medium Component: libdrm AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: s...@netbsd.org Created an attachment (id=26565) --> (http://bugs.freedesktop.org/attachment.cgi?id=26565) Patch to set DRM_MAJOR correctly (180) on NetBSD. libdrm has two different values (!) for DRM_MAJOR on NetBSD, and both of them are wrong. This is a major (har har har) problem. NetBSD uses a major number of 180, so I've attached a patch to correct it. We've been using this in our pkgsrc and xsrc trees for quite some time. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13490] after some time of inactivity display turns black - requires hard restart
http://bugzilla.kernel.org/show_bug.cgi?id=13490 --- Comment #2 from Khashayar Naderehvandi 2009-06-08 21:35:43 --- Sorry, I forgot to mention the hardware. I'm seeing this on a GM965 (Dell XPS m1330) as well as a G45 (Asus N20A). The snippet above is from the GM965 laptop. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13490] New: after some time of inactivity display turns black - requires hard restart
http://bugzilla.kernel.org/show_bug.cgi?id=13490 Summary: after some time of inactivity display turns black - requires hard restart Product: Drivers Version: 2.5 Kernel Version: 2.6.30-rc8 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: khashayar.li...@gmail.com Regression: No I'm using an up-to-date Xorg stack from the ubuntu xorg-edgers PPA on ubuntu 9.04. and kernel 2.6.30-rc8 from Ubuntu's mainline builds. After some time of inactivity, the screen turns dark and the only way to proceed is through a sysrq+REISUB. dmesg shows me this: [ 31.511419] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 32.865067] padlock: VIA PadLock not detected. [ 42.260047] wlan0: no IPv6 routers present [ 91.717152] CE: hpet increasing min_delta_ns to 15000 nsec [ 103.692112] CE: hpet increasing min_delta_ns to 22500 nsec [ 213.670931] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 [ 4440.721189] INFO: task events/0:9 blocked for more than 120 seconds. [ 4440.721196] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4440.721201] events/0 D f0ea7d3c 0 9 2 [ 4440.721210] f7077f20 0046 f72fa000 f0ea7d3c 03e9 f5943a40 [ 4440.721225] c07c5ee0 c07c5ee0 f7036ff0 f7037284 c201bee0 f0ea91f2 03e9 [ 4440.721239] f7037284 f6b5fc18 f6b5fc14 f7077f4c c053fcfe f7077f4c f7036ff0 [ 4440.721252] Call Trace: [ 4440.721266] [] __mutex_lock_slowpath+0xbe/0x120 [ 4440.721273] [] mutex_lock+0x20/0x40 [ 4440.721300] [] i915_gem_retire_work_handler+0x28/0x70 [i915] [ 4440.721309] [] run_workqueue+0x95/0x130 [ 4440.721329] [] ? i915_gem_retire_work_handler+0x0/0x70 [i915] [ 4440.721336] [] worker_thread+0x88/0xf0 [ 4440.721345] [] ? autoremove_wake_function+0x0/0x50 [ 4440.721352] [] ? worker_thread+0x0/0xf0 [ 4440.721359] [] kthread+0x46/0x80 [ 4440.721365] [] ? kthread+0x0/0x80 [ 4440.721373] [] kernel_thread_helper+0x7/0x10 [ 4440.721410] INFO: task compiz.real:4649 blocked for more than 120 seconds. [ 4440.721414] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4440.721419] compiz.real D e3679024 0 4649 4590 [ 4440.721426] f52a1e34 00200082 f5a73200 e3679024 03eb 0001 f5943a40 [ 4440.721441] c07c5ee0 c07c5ee0 f66e4aa0 f66e4d34 c201bee0 [ 4440.721454] f66e4d34 f6b5fc18 f6b5fc14 f52a1e60 c053fcfe c0452f71 f66e4aa0 [ 4440.721468] Call Trace: [ 4440.721476] [] __mutex_lock_slowpath+0xbe/0x120 [ 4440.721483] [] ? __sock_recvmsg+0x61/0x70 [ 4440.721490] [] mutex_lock+0x20/0x40 [ 4440.721512] [] i915_gem_set_domain_ioctl+0x7a/0xe0 [i915] [ 4440.721541] [] drm_ioctl+0x13a/0x3a0 [drm] [ 4440.721562] [] ? i915_gem_set_domain_ioctl+0x0/0xe0 [i915] [ 4440.721571] [] ? security_file_permission+0xf/0x20 [ 4440.721580] [] ? autoremove_wake_function+0x0/0x50 [ 4440.721592] [] vfs_ioctl+0x79/0x90 [ 4440.721599] [] do_vfs_ioctl+0x72/0x2d0 [ 4440.721605] [] sys_ioctl+0x63/0x70 [ 4440.721612] [] syscall_call+0x7/0xb [ 4560.720156] INFO: task events/0:9 blocked for more than 120 seconds. [ 4560.720163] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4560.720169] events/0 D f0ea7d3c 0 9 2 [ 4560.720177] f7077f20 0046 f72fa000 f0ea7d3c 03e9 f5943a40 [ 4560.720192] c07c5ee0 c07c5ee0 f7036ff0 f7037284 c201bee0 f0ea91f2 03e9 [ 4560.720206] f7037284 f6b5fc18 f6b5fc14 f7077f4c c053fcfe f7077f4c f7036ff0 [ 4560.720220] Call Trace: [ 4560.720234] [] __mutex_lock_slowpath+0xbe/0x120 [ 4560.720241] [] mutex_lock+0x20/0x40 [ 4560.720268] [] i915_gem_retire_work_handler+0x28/0x70 [i915] [ 4560.720277] [] run_workqueue+0x95/0x130 [ 4560.720297] [] ? i915_gem_retire_work_handler+0x0/0x70 [i915] [ 4560.720305] [] worker_thread+0x88/0xf0 [ 4560.720313] [] ? autoremove_wake_function+0x0/0x50 [ 4560.720320] [] ? worker_thread+0x0/0xf0 [ 4560.720327] [] kthread+0x46/0x80 [ 4560.720334] [] ? kthread+0x0/0x80 [ 4560.720342] [] kernel_thread_helper+0x7/0x10 [ 4560.720379] INFO: task compiz.real:4649 blocked for more than 120 seconds. [ 4560.720383] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4560.720387] compiz.real D e3679024 0 4649 4590 [ 4560.720395] f52a1e34 00200082 f5a73200 e3679024 03eb 0001 f5943a40 [ 4560.720410] c07c5ee0 c07c5ee0 f66e4aa0 f66e4d34 c201bee0 [ 4560.720423] f66e4d34 f6b5fc18 f6b5fc14 f52a1e60 c053fcfe c0452f71 f66e4aa0 [ 4560.720436] Call Trace: [ 4560.720445] [] __mutex_lock_slowpath+0xbe/0x120 [ 4560.720452] [] ? __sock_r
[Bug 13294] i915: drm: xorg leaks drm objects massively
http://bugzilla.kernel.org/show_bug.cgi?id=13294 --- Comment #9 from Sergei Trofimovich 2009-06-08 19:47:18 --- All problems disappear when I enable i915 KMS. Xorg VSIZE reduces from 500M to 200M, VT switch does not cause any warnings. So, bug only appears in non-KMS mode. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Intel-gfx] [PATCH] drm: remove mode from list and destroy it in order
Any comments ?
Thanks
Ma Ling
>-Original Message-
>From: intel-gfx-boun...@lists.freedesktop.org
>[mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ma Ling
>Sent: Friday, June 05, 2009 5:16 PM
>To: dri-devel@lists.sourceforge.net
>Cc: intel-...@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH] drm: remove mode from list and
>destroy it in order
>
>Usually We create drm mode by drm_mode_create function which
>also will assign ID
>to this mode by drm_mode_object_get function, then insert this
>new mode into
>mode list by list_add function. So when destroying mode, we
>need to remove mode
>from list, then free ID and allocated memory by
>drm_mode_destroy function,
>otherwise memory leak.
>
>Signed-off-by: Ma Ling
>---
> drivers/gpu/drm/drm_crtc.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>index 94a7688..03a7b30 100644
>--- a/drivers/gpu/drm/drm_crtc.c
>+++ b/drivers/gpu/drm/drm_crtc.c
>@@ -423,7 +423,6 @@ void drm_mode_remove(struct drm_connector
>*connector,
>struct drm_display_mode *mode)
> {
> list_del(&mode->head);
>- kfree(mode);
> }
> EXPORT_SYMBOL(drm_mode_remove);
>
>@@ -485,14 +484,20 @@ void drm_connector_cleanup(struct
>drm_connector *connector)
> struct drm_device *dev = connector->dev;
> struct drm_display_mode *mode, *t;
>
>- list_for_each_entry_safe(mode, t,
>&connector->probed_modes, head)
>+ list_for_each_entry_safe(mode, t,
>&connector->probed_modes, head) {
> drm_mode_remove(connector, mode);
>+ drm_mode_destroy(dev, mode);
>+ }
>
>- list_for_each_entry_safe(mode, t, &connector->modes, head)
>+ list_for_each_entry_safe(mode, t, &connector->modes, head) {
> drm_mode_remove(connector, mode);
>+ drm_mode_destroy(dev, mode);
>+ }
>
>- list_for_each_entry_safe(mode, t, &connector->user_modes, head)
>+ list_for_each_entry_safe(mode, t,
>&connector->user_modes, head) {
> drm_mode_remove(connector, mode);
>+ drm_mode_destroy(dev, mode);
>+ }
>
> mutex_lock(&dev->mode_config.mutex);
> drm_mode_object_put(dev, &connector->base);
>--
>1.5.4.4
>
>
>
>___
>Intel-gfx mailing list
>intel-...@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22017] Incorrect Colours Radeon 9200 - Mesa 7.4-1
http://bugs.freedesktop.org/show_bug.cgi?id=22017 --- Comment #10 from Phil Armstrong 2009-06-08 07:25:18 PST --- >I've been using 3D hardware acceleration (with correct colours ;) on various >PowerMacs for almost a decade, and fixing bugs as I was aware of them. It's >hard to fix bugs you don't know about... I appreciate that! I'll try and nail down the problematic release. Assuming there's not some weird heisenbug thing going on of course. It seems to work fine with Xorg 1.4 series releases at least, which suggests a change in the 1.4->1.6 transition. Will confirm later. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22153] X Locks Hard on Totem Transitions between Windowed and Full Screen
http://bugs.freedesktop.org/show_bug.cgi?id=22153 --- Comment #1 from cakristof 2009-06-08 06:49:06 PST --- Created an attachment (id=26547) --> (http://bugs.freedesktop.org/attachment.cgi?id=26547) /var/log/messages -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22017] Incorrect Colours Radeon 9200 - Mesa 7.4-1
http://bugs.freedesktop.org/show_bug.cgi?id=22017 --- Comment #9 from Michel Dänzer 2009-06-08 06:59:59 PST --- (In reply to comment #8) > bisecting the radeon driver may be tricky though: IIRC it has a dependency on > the new X server. There should only be an ABI dependency between binaries, no source level dependency. What are the good/bad versions of xf86-video-ati? (In reply to comment #5) > The software renderer for mesa git head (seting LIBGL_ALWAYS_SOFTWARE=1) gets > the colours wrong as well. That's a separate issue which would need to be tracked separately. (In reply to comment #3) > It's been the case for ages that mesa renders colours incorrectly on radeon > cards on powerpc platforms: it happens both on the G4 laptop & G4 mac mini I > have. > > Sorry I never got around to reporting it: turning on dri locks up my laptop & > I > only just acquired the mac mini which confirmed the bug. I've been using 3D hardware acceleration (with correct colours ;) on various PowerMacs for almost a decade, and fixing bugs as I was aware of them. It's hard to fix bugs you don't know about... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22153] X Locks Hard on Totem Transitions between Windowed and Full Screen
http://bugs.freedesktop.org/show_bug.cgi?id=22153 cakristof changed: What|Removed |Added Attachment #26546|Xorg.0.log |Xorg.0.log.bz2 description|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22153] X Locks Hard on Totem Transitions between Windowed and Full Screen
http://bugs.freedesktop.org/show_bug.cgi?id=22153 cakristof changed: What|Removed |Added Attachment #26547|/var/log/messages |/var/log/messages.bz2 description|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22153] New: X Locks Hard on Totem Transitions between Windowed and Full Screen
http://bugs.freedesktop.org/show_bug.cgi?id=22153 Summary: X Locks Hard on Totem Transitions between Windowed and Full Screen Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: cakris...@gmail.com Created an attachment (id=26546) --> (http://bugs.freedesktop.org/attachment.cgi?id=26546) Xorg.0.log I've been seeing occasional hard locking of X when I change the size of my video player from windowed to full screen or from full screen to windowed. Here's my setup: Debian Squeeze AMD64 Kernel 2.6.30-rc5 (self compiled) Xorg 7.4 (self-compiled) Gnome 2.26.1 (debian packages) Totem 2.26.2 (debian package) radeonhd (I git pull every 2-3 days.) drm (native, built into kernel 2.6.30) Two 1920x1200 panels over DVI DVI-I_1/digital is Left Panel DVI-I_2/digital is Right Panel I've been using randr to disable the left monitor when I watch videos. This seems to be a necessary condition for the bug. I see the bug when running totem on the remaining right display. X locks hard when totem transitions between full screen and windowed mode. It happens on both directions. All keyboard input is ignored. I have to ssh in and kill X. It's always at 100% cpu utilization. This doesn't happen on every transition between windowed and full screen but it happens often enough. I've been using the power switch to disable my left monitor. I want to verify that the bug happens only when randr is used to disable the left screen. It has been proven true so far. I have tried the "radeon-test-ring.patch" from Bug 21849. It didn't help. The logs attached were produced wile running a kernel with that patch. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
yakui_zhao wrote: > Sometimes we can see the register snapshot without using the > intel-gpu-tools. For example: in UMS mode we often get the register > snapshot several times in starting X. > > It will be good that we expose the raw register values and then they are > parsed by intel-gpu-tools if we need to extend the decode. > > How about adding two debugfs I/F? One is to dump the raw register > snapshot(without decode and format). Another is what I have done in the > patch. > Why not just expose the raw register values in debugfs, and copy them to one side for intel-gpu-tools to deal with whenever you get to an interesting point? Should be as simple (in userspace) as "cp /sys/kernel/debug/dri/0/registers ~/dump" at interesting points. -- Simon Farnsworth -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend3] [Intel-gfx] [PATCH 0/3] Add the default mode for LVDS in KMS mode
Hi, All the following is the patch set that adds the default modes for LVDS in KMS mode. Patch 1/3: Add a private data for LVDS When the connector type is LVDS, it will add a private data that can be used to store the LVDS panel limit. For example: hdisplay, vdisplay. Patch 2/3: Get the LVDS panel limit and check whether the given modeline is valid Traverse the mode list returned by KMS kernel to get the LVDS panel limit. And the panel limit is used to check whether the given modeline is valid. Patch 3/3: Fix the EDID for LVDS output device to add the default modes This is similar to what we have done in UMS mode a. When there exists the EDID, either find a DS_RANGES block or replace a DS_VENDOR block , smashing it into a DS_RANGES block with open refresh to match all the default modes. b. When there is no EDID, we will construct a bogus EDID and add a DS_RANGES block with open refresh to match all the default modes. welcome the comments. Best regards Yakui -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend2][Intel-gfx] [PATCH 3/3] Fix EDID for LVDS output device to add the default modes
Fix the EDID for the LVDS output device to add the default modes.This is
similar to what we have done in UMS mode.
a. When there exists the EDID, either find the DS_RANGES block or replace
a DS_VENDOR block, smashing it into a DS_RANGES block with open refresh
to match all the defaults modes.
b. When there is no EDID, we will construct a bogus EDID and add a DS_RANGES
block with the open refresh to match all the default modes.
Signed-off-by: Zhao Yakui
---
src/drmmode_display.c | 128 ++
1 file changed, 128 insertions(+)
Index: xf86_video_intel/src/drmmode_display.c
===
--- xf86_video_intel.orig/src/drmmode_display.c 2009-06-08 10:01:06.0
+0800
+++ xf86_video_intel/src/drmmode_display.c 2009-06-08 10:01:13.0
+0800
@@ -489,6 +489,133 @@
return MODE_OK;
}
+static void fill_detailed_lvds_block (
+ struct detailed_monitor_section *det_mon,
+ DisplayModePtr mode)
+{
+struct detailed_timings *timing = &det_mon->section.d_timings;
+det_mon->type = DT;
+timing->clock = mode->Clock * 1000;
+timing->h_active = mode->HDisplay;
+timing->h_blanking = mode->HTotal - mode->HDisplay;
+timing->v_active = mode->VDisplay;
+timing->v_blanking = mode->VTotal - mode->VDisplay;
+timing->h_sync_off = mode->HSyncStart - mode->HDisplay;
+timing->h_sync_width = mode->HSyncEnd - mode->HSyncStart;
+timing->v_sync_off = mode->VSyncStart - mode->VDisplay;
+timing->v_sync_width = mode->VSyncEnd - mode->VSyncStart;
+
+if (mode->Flags & V_PVSYNC)
+timing->misc |= 0x02;
+
+if (mode->Flags & V_PHSYNC)
+timing->misc |= 0x01;
+}
+
+static int drmmode_output_lvds_edid(xf86OutputPtr output,
+ struct fixed_panel_lvds *p_lvds)
+{
+ drmmode_output_private_ptr drmmode_output = output->driver_private;
+ drmModeConnectorPtr koutput = drmmode_output->mode_output;
+ int i, j;
+ DisplayModePtr pmode;
+ xf86MonPtr edid_mon;
+ drmModeModeInfo *mode_ptr;
+ struct detailed_monitor_section *det_mon;
+
+ if (output->MonInfo) {
+ /*
+* If there exists the EDID, we will either find a DS_RANGES
+* or replace a DS_VENDOR block, smashing it into a DS_RANGES
+* block with opern refresh to match all the default modes.
+*/
+ int edid_det_block_num;
+ edid_mon = output->MonInfo;
+ edid_mon->features.msc |= 0x01;
+ j = -1;
+ edid_det_block_num = sizeof(edid_mon->det_mon) /
+ sizeof(edid_mon->det_mon[0]);
+ for (i = 0; i < edid_det_block_num; i++)
+ {
+ if (edid_mon->det_mon[i].type >= DS_VENDOR && j == -1)
+ j = i;
+ if (edid_mon->det_mon[i].type == DS_RANGES) {
+ j = i;
+ break;
+ }
+ }
+ if (j != -1) {
+ struct monitor_ranges *ranges =
+ &edid_mon->det_mon[j].section.ranges;
+ edid_mon->det_mon[j].type = DS_RANGES;
+ ranges->min_v = 0;
+ ranges->max_v = 200;
+ ranges->min_h = 0;
+ ranges->max_h = 200;
+ }
+ return 0;
+ }
+ /*
+* If there is no EDID, we will construct a bogus EDID for LVDS output
+* device. This is similar to what we have done in i830_lvds.c
+*/
+ edid_mon = NULL;
+ edid_mon = xcalloc(1, sizeof(xf86Monitor));
+ if (!edid_mon) {
+ xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+ "Can't allocate memory for edid_mon.\n");
+ return 0;
+ }
+ /* Find the fixed panel mode.
+* In theory when there is no EDID, KMS kernel will return only one
+* mode. And this can be regarded as fixed lvds panel mode.
+* But it will be better to traverse the mode list to get the fixed
+* lvds panel mode again as we don't know whether some new modes
+* are added for the LVDS output device
+*/
+ j = 0;
+ for (i = 0; i < koutput->count_modes; i++) {
+ mode_ptr = &koutput->modes[i];
+ if ((mode_ptr->hdisplay == p_lvds->hdisplay) &&
+ (mode_ptr->vdisplay == p_lvds->vdisplay)) {
+ /* find the fixed panel mode */
+ j = i;
+ break;
+ }
+ }
+ pmode = xnfalloc(sizeof(DisplayModeRec));
+ drmmode_ConvertFromKMode(output->scrn, &koutput->modes[j], pmode);
+
[Resend] [Intel-gfx] [PATCH 0/3] use the sdvo device info parsed from VBT to initialize SDVO device
Hi, The following is the patch set that use the SDVO device info parsed from general definition block to initialize the SDVO device. It is to fix the following bug: http://bugs.freedesktop.org/show_bug.cgi?id=20429 By parsing the general definition block of VBT we can get the relationship between the DVO port and slave address. For example: the SDVO wiring, the SDVO slave address. And then we use the info to initialize the SDVO device. If the slave address can obtained for SDVO port(SDVOB/SDVOC), it will be initialized correctly. If no slave address is found in the SDVO device info parsed from VBT, it will return the slave address by using the following flowchart: a. If the SDVO device info is found for another SDVO port, it will return the slave address that is not used. For example: if 0x70 is used, then 0x72 is returned. If 0x72 is used, 0x70 is returned. b. If no SDVO device info is found for another SDVO port, it will return 0x70 for SDVOB and 0x72 for SDVOC. Patch 01/3: Dynamically get the number of child device in general definition block Patch 02/3: parse general definition block to get the SDVO device info. Patch 03/3: Initialize the SDVO device based on the the sdvo device info parsed from general definition block Welcome the comments. Yakui -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend] [Intel-gfx] [PATCH 3/3] Initialize the SDVO device based on the sdvo info parsed from VBT
Subject: GFX: Initialize the SDVO device based on the valid slave address
From: Zhao Yakui
When the slave address is found for the SDVO port, the SDVO device will
be initialzied.
When the slave address is not found for the SDVO port, it will return
the slave address by using the following flowchart:
a. If the SDVO device info is found for another SDVO port, it will return
the slave address that is not used. For example: if 0x70 is used, then 0x72
is returned.
b. If no SDVO device info is found for another SDVO port, it will return
0x70 for SDVOB and 0x72 for SDVOC.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui
---
src/i830_sdvo.c | 73
1 file changed, 69 insertions(+), 4 deletions(-)
Index: xf86_video_intel/src/i830_sdvo.c
===
--- xf86_video_intel.orig/src/i830_sdvo.c 2009-06-08 10:12:20.0
+0800
+++ xf86_video_intel/src/i830_sdvo.c2009-06-08 10:15:25.0 +0800
@@ -1038,7 +1038,6 @@
/* Set the input timing to the screen. Assume always input 0. */
i830_sdvo_set_target_input(output, TRUE, FALSE);
-
success = i830_sdvo_create_preferred_input_timing(output,
mode->Clock / 10,
mode->HDisplay,
@@ -2135,7 +2134,71 @@
/* Corresponds to SDVO_CONTROL_BUS_DDCx */
dev_priv->ddc_bus = 1 << num_bits;
}
+/**
+ * find the slave address for the given SDVO port based on the info
+ * parsed in general definition blocks
+ * If the slave address is found in the SDVO device info parsed from
+ * VBT,it will be returned. Otherwise it will return the slave address
+ * by the following steps.
+ * and 0x72 for SDVOC port.
+ * a. If one SDVO device info is found in another DVO port, it will return
+ * the slave address that is not used. For example: if 0x70 is used,
+ * then 0x72 is returned.
+ * b. If no SDVO device info is found in another DVO port, it will return
+ * 0x70 for SDVOB and 0x72 for SDVOC port.
+ */
+static
+void i830_find_sdvo_slave(ScrnInfoPtr pScrn, int output_device,
+ uint8_t *slave_addr)
+{
+uint8_t temp_slave_addr;
+I830Ptr pI830 = I830PTR(pScrn);
+uint8_t dvo_port, dvo2_port;
+struct sdvo_device_mapping *p_mapping;
+if (output_device == SDVOB) {
+ /* DEVICE_PORT_DVOB */
+ dvo_port = 0;
+ dvo2_port = 1;
+}
+else {
+ /* DEVICE_POTR_DVOC */
+ dvo_port = 1;
+ dvo2_port = 0;
+}
+
+p_mapping = &(pI830->sdvo_mappings[dvo_port]);
+temp_slave_addr = p_mapping->slave_addr;
+if (temp_slave_addr) {
+ /* slave address is found . return it */
+ *slave_addr = temp_slave_addr;
+ return ;
+}
+/* Check whether the SDVO device info is found in another dvo port */
+p_mapping = &(pI830->sdvo_mappings[dvo2_port]);
+temp_slave_addr = p_mapping->slave_addr;
+if (!temp_slave_addr) {
+/* no SDVO device is found in another DVO port */
+ /* it will return 0x70 for SDVOB and 0x72 for SDVOC */
+ if (output_device == SDVOB)
+ temp_slave_addr = 0x70;
+ else
+ temp_slave_addr = 0x72;
+ *slave_addr = temp_slave_addr;
+ return ;
+}
+/* return the slave address that is not used.
+ * If the 0x70 is used, then 0x72 is returned.
+ * If the 0x72 is used, then 0x70 is returned.
+ */
+if (temp_slave_addr == 0x70)
+ temp_slave_addr = 0x72;
+else
+ temp_slave_addr = 0x70;
+
+*slave_addr = temp_slave_addr;
+return ;
+}
Bool
i830_sdvo_init(ScrnInfoPtr pScrn, int output_device)
{
@@ -2145,6 +2208,10 @@
inti;
unsigned char ch[0x40];
I2CBusPtr i2cbus = NULL, ddcbus;
+uint8_t slave_addr;
+
+slave_addr = 0;
+i830_find_sdvo_slave(pScrn, output_device, &slave_addr);
output = xf86OutputCreate (pScrn, &i830_sdvo_output_funcs,NULL);
if (!output)
@@ -2180,14 +2247,12 @@
xf86OutputDestroy (output);
return FALSE;
}
-
if (output_device == SDVOB) {
dev_priv->d.DevName = "SDVO Controller B";
- dev_priv->d.SlaveAddr = 0x70;
} else {
dev_priv->d.DevName = "SDVO Controller C";
- dev_priv->d.SlaveAddr = 0x72;
}
+dev_priv->d.SlaveAddr = slave_addr;
dev_priv->d.pI2CBus = i2cbus;
dev_priv->d.DriverPrivate.ptr = output;
dev_priv->output_device = output_device;
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
On Fri, 2009-06-05 at 19:11 +0800, Eric Anholt wrote: > On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote: > > It is useful to get the register snapshot. > > Add a debugfs I/F named "i915_reg" to dump the I915 register snapshot. And > > this > > is created under the dri/0/ of debugfs. > > The output format is similar to what we have done in UMS mode. > > I don't think that all the decode and formatting of these registers > should be in the kernel. Every time I've had to mess with register > decode stuff for investigation, I've needed to extend the decode. > Instead, we should expose the raw register values and make > intel_reg_dumper in intel-gpu-tools that does the decode of actual > meaning. Sometimes we can see the register snapshot without using the intel-gpu-tools. For example: in UMS mode we often get the register snapshot several times in starting X. It will be good that we expose the raw register values and then they are parsed by intel-gpu-tools if we need to extend the decode. How about adding two debugfs I/F? One is to dump the raw register snapshot(without decode and format). Another is what I have done in the patch. What format should be used when dumping the raw register values? >register name: register value Thanks. > -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend2][Intel-gfx] [PATCH 1/3] Add the private data for the LVDS connector
Add the private data when the connector type is LVDS.
We can use the private_data to store the LVDS panel limit.
For example: Hdisplay, Vdisplay
Signed-off-by: Zhao Yakui
---
src/drmmode_display.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
Index: xf86_video_intel/src/drmmode_display.c
===
--- xf86_video_intel.orig/src/drmmode_display.c 2009-05-26 11:12:39.0
+0800
+++ xf86_video_intel/src/drmmode_display.c 2009-06-08 10:00:55.0
+0800
@@ -58,6 +58,10 @@
Atom *atoms;
} drmmode_prop_rec, *drmmode_prop_ptr;
+struct fixed_panel_lvds {
+ int hdisplay;
+ int vdisplay;
+};
typedef struct {
drmmode_ptr drmmode;
int output_id;
@@ -66,6 +70,8 @@
drmModePropertyBlobPtr edid_blob;
int num_props;
drmmode_prop_ptr props;
+ void *private_data;
+ /* this is used to store private data */
} drmmode_output_private_rec, *drmmode_output_private_ptr;
static void
@@ -529,6 +535,10 @@
}
xfree(drmmode_output->props);
drmModeFreeConnector(drmmode_output->mode_output);
+ if (drmmode_output->private_data) {
+ xfree(drmmode_output->private_data);
+ drmmode_output->private_data = NULL;
+ }
xfree(drmmode_output);
output->driver_private = NULL;
}
@@ -792,7 +802,19 @@
drmModeFreeEncoder(kencoder);
return;
}
-
+ /*
+* If the connector type of the output device is LVDS, we will
+* allocate the private_data to store the panel limit.
+* For example: hdisplay, vdisplay
+*/
+ drmmode_output->private_data = NULL;
+ if (koutput->connector_type == DRM_MODE_CONNECTOR_LVDS) {
+ drmmode_output->private_data = xcalloc(
+ sizeof(struct fixed_panel_lvds), 1);
+ if (!drmmode_output->private_data)
+ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "Can't allocate private memory for LVDS.\n");
+ }
drmmode_output->output_id = drmmode->mode_res->connectors[num];
drmmode_output->mode_output = koutput;
drmmode_output->mode_encoder = kencoder;
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend2][Intel-gfx] [PATCH 0/3] Add the default mode for LVDS in KMS mode
Hi, All the following is the patch set that adds the default modes for LVDS in KMS mode. It is to solve the following bugs: http://bugs.freedesktop.org/show_bug.cgi?id=20801 http://bugs.freedesktop.org/show_bug.cgi?id=21094 http://bugs.freedesktop.org/show_bug.cgi?id=21346 http://bugs.freedesktop.org/show_bug.cgi?id=21417 http://bugs.freedesktop.org/show_bug.cgi?id=21671 Patch 1/3: Add a private data for LVDS When the connector type is LVDS, it will add a private data that can be used to store the LVDS panel limit. For example: hdisplay, vdisplay. Patch 2/3: Get the LVDS panel limit and check whether the given modeline is valid Traverse the mode list returned by KMS kernel to get the LVDS panel limit. And the panel limit is used to check whether the given modeline is valid. Patch 3/3: Add the default modes for the LVDS This is similar to what we have done in UMS mode a. When there exists the EDID, either find a DS_RANGES block or replace a DS_VENDOR block , smashing it into a DS_RANGES block with open refresh to match all the default modes. b. When there is no EDID, we will construct a bogus EDID and add a DS_RANGES block with open refresh to match all the default modes welcome the comments. Best regards Yakui -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend][Intel-gfx] [PATCH 1/3] Dynamically get the number of child device in general definition block
The size of general definition block varies on different platform/machines.
In such case the number of child device is also different.
And it will be better to get the number of child device in general definition
block dynamically.
The number of child device can be calculated by the following formula:
(block_size - block_header_size) /
sizeof( struct child_device_config)
Signed-off-by: Zhao Yakui
---
src/bios_reader/bios_reader.c |4 +++-
src/i830_bios.h |2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
Index: xf86_video_intel/src/bios_reader/bios_reader.c
===
--- xf86_video_intel.orig/src/bios_reader/bios_reader.c 2009-06-08
10:07:49.0 +0800
+++ xf86_video_intel/src/bios_reader/bios_reader.c 2009-06-08
10:07:51.0 +0800
@@ -170,6 +170,7 @@
struct child_device_config *child;
int i;
char child_id[11];
+int child_device_num;
block = find_section(BDB_GENERAL_DEFINITIONS);
@@ -188,7 +189,8 @@
printf("\tBoot display type: 0x%02x%02x\n", defs->boot_display[1],
defs->boot_display[0]);
printf("\tTV data block present: %s\n", YESNO(tv_present));
-for (i = 0; i < 4; i++) {
+child_device_num = (block->size - sizeof(*defs)) / sizeof(*child);
+for (i = 0; i < child_device_num; i++) {
child = &defs->devices[i];
if (!child->device_type) {
printf("\tChild device %d not present\n", i);
Index: xf86_video_intel/src/i830_bios.h
===
--- xf86_video_intel.orig/src/i830_bios.h 2009-06-08 10:07:23.0
+0800
+++ xf86_video_intel/src/i830_bios.h2009-06-08 10:07:51.0 +0800
@@ -228,7 +228,7 @@
* TV and LVDS are missing, so be careful when interpreting
* [4] and [5].
*/
- struct child_device_config devices[6];
+ struct child_device_config devices[0];
/* may be another device block here on some platforms */
} __attribute__((packed));
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend2] [Intel-gfx] [PATCH 2/3] Get the LVDS panel limit and check whether the given modeline is valid
When the connector type is LVDS, it will traverse the mode list returned by KMS
kernel to
get the LVDS panel limit.
Then it will use the panel limit to check whether the given modeline is valid.
If the given modeline exceeds the LVDS panel limit, it will be invalid.
Signed-off-by: Zhao Yakui
---
src/drmmode_display.c | 38 ++
1 file changed, 38 insertions(+)
Index: xf86_video_intel/src/drmmode_display.c
===
--- xf86_video_intel.orig/src/drmmode_display.c 2009-06-08 10:00:55.0
+0800
+++ xf86_video_intel/src/drmmode_display.c 2009-06-08 10:01:06.0
+0800
@@ -471,6 +471,21 @@
static Bool
drmmode_output_mode_valid(xf86OutputPtr output, DisplayModePtr pModes)
{
+ drmmode_output_private_ptr drmmode_output = output->driver_private;
+ drmModeConnectorPtr koutput = drmmode_output->mode_output;
+ struct fixed_panel_lvds *p_lvds = drmmode_output->private_data;
+
+ /*
+* If the connector type is LVDS, we will use the panel limit to
+* verfiy whether the mode is valid.
+*/
+ if ((koutput->connector_type == DRM_MODE_CONNECTOR_LVDS) && p_lvds) {
+ if (pModes->HDisplay > p_lvds->hdisplay ||
+ pModes->VDisplay > p_lvds->vdisplay)
+ return MODE_PANEL;
+ else
+ return MODE_OK;
+ }
return MODE_OK;
}
@@ -483,6 +498,8 @@
int i;
DisplayModePtr Modes = NULL, Mode;
drmModePropertyPtr props;
+ struct fixed_panel_lvds *p_lvds;
+ drmModeModeInfo *mode_ptr;
/* look for an EDID property */
for (i = 0; i < koutput->count_props; i++) {
@@ -518,6 +535,27 @@
Modes = xf86ModesAdd(Modes, Mode);
}
+ p_lvds = drmmode_output->private_data;
+ /*
+* If the connector type is LVDS, we will traverse the kernel mode to
+* get the panel limit.
+* If it is incorrect, please fix me.
+*/
+ if ((koutput->connector_type == DRM_MODE_CONNECTOR_LVDS) && p_lvds) {
+ p_lvds->hdisplay = 0;
+ p_lvds->vdisplay = 0;
+ for (i = 0; i < koutput->count_modes; i++) {
+ mode_ptr = &koutput->modes[i];
+ if ((mode_ptr->hdisplay >= p_lvds->hdisplay) &&
+ (mode_ptr->vdisplay >= p_lvds->vdisplay)) {
+ p_lvds->hdisplay = mode_ptr->hdisplay;
+ p_lvds->vdisplay = mode_ptr->vdisplay;
+ }
+ }
+ if (!p_lvds->hdisplay || !p_lvds->vdisplay)
+ xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+ "Incorrect KMS mode.\n");
+ }
return Modes;
}
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Resend3] [Intel-gfx][Patch_v2] DRM/I915: Sync the LVDS panel fitting property with 2D driver
This covers:
a. create the scaling mode property and attach it to LVDS
b. add the support of panel fitting property for LVDS
c. update the display mode according to the panel fitting mode
v2: the drm_calloc/drm_free is replaced by kzalloc/kfree based
on Eric's suggestion.
Without this patch, we still can't use the different LVDS panel fitting
mode(center,
full-aspect, full-scaling) even when we can get the same mode lines as in UMS
mode.
Signed-off-by: Zhao Yakui
---
drivers/gpu/drm/i915/i915_reg.h | 16 ++
drivers/gpu/drm/i915/intel_lvds.c | 282 +++---
2 files changed, 277 insertions(+), 21 deletions(-)
Index: linux-2.6/drivers/gpu/drm/i915/i915_reg.h
===
--- linux-2.6.orig/drivers/gpu/drm/i915/i915_reg.h 2009-06-08
09:47:08.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/i915_reg.h 2009-06-08 09:47:37.0
+0800
@@ -834,9 +834,25 @@
#define HORIZ_INTERP_MASK(3 << 6)
#define HORIZ_AUTO_SCALE (1 << 5)
#define PANEL_8TO6_DITHER_ENABLE (1 << 3)
+#define PFIT_FILTER_FUZZY(0 << 24)
+#define PFIT_SCALING_AUTO(0 << 26)
+#define PFIT_SCALING_PROGRAMMED (1 << 26)
+#define PFIT_SCALING_PILLAR (2 << 26)
+#define PFIT_SCALING_LETTER (3 << 26)
#define PFIT_PGM_RATIOS0x61234
#define PFIT_VERT_SCALE_MASK 0xfff0
#define PFIT_HORIZ_SCALE_MASK0xfff0
+/* Pre-965 */
+#definePFIT_VERT_SCALE_SHIFT 20
+#definePFIT_VERT_SCALE_MASK0xfff0
+#definePFIT_HORIZ_SCALE_SHIFT 4
+#definePFIT_HORIZ_SCALE_MASK 0xfff0
+/* 965+ */
+#definePFIT_VERT_SCALE_SHIFT_965 16
+#definePFIT_VERT_SCALE_MASK_9650x1fff
+#definePFIT_HORIZ_SCALE_SHIFT_965 0
+#definePFIT_HORIZ_SCALE_MASK_965 0x1fff
+
#define PFIT_AUTO_RATIOS 0x61238
/* Backlight control */
Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c2009-06-08
09:47:08.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c 2009-06-08 09:47:37.0
+0800
@@ -37,6 +37,21 @@
#include "i915_drm.h"
#include "i915_drv.h"
+/*
+ * the following four scaling options are defined.
+ * #define DRM_MODE_SCALE_NON_GPU 0
+ * #define DRM_MODE_SCALE_FULLSCREEN 1
+ * #define DRM_MODE_SCALE_NO_SCALE 2
+ * #define DRM_MODE_SCALE_ASPECT 3
+ */
+
+/* Private structure for the integrated LVDS support */
+struct intel_lvds_priv {
+ int fitting_mode;
+ u32 pfit_control;
+ u32 pfit_pgm_ratios;
+};
+
/**
* Sets the backlight level.
*
@@ -211,10 +226,24 @@
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ /*
+* float point operation is not supported . So the PANEL_RATIO_FACTOR
+* is defined, which can avoid the float point computation when
+* calculating the panel ratio.
+*/
+#define PANEL_RATIO_FACTOR 8192
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
struct drm_encoder *tmp_encoder;
+ struct intel_output *intel_output = enc_to_intel_output(encoder);
+ struct intel_lvds_priv *lvds_priv = intel_output->dev_priv;
+ u32 pfit_control = 0, pfit_pgm_ratios = 0;
+ int left_border = 0, right_border = 0, top_border = 0;
+ int bottom_border = 0;
+ bool border = 0;
+ int panel_ratio, desired_ratio, vert_scale, horiz_scale;
+ int horiz_ratio, vert_ratio;
/* Should never happen!! */
if (!IS_I965G(dev) && intel_crtc->pipe == 0) {
@@ -230,7 +259,9 @@
return false;
}
}
-
+ /* If we don't have a panel mode, there is nothing we can do */
+ if (dev_priv->panel_fixed_mode == NULL)
+ return true;
/*
* If we have timings from the BIOS for the panel, put them in
* to the adjusted mode. The CRTC will be set up for this mode,
@@ -254,6 +285,191 @@
drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
}
+ /* Make sure pre-965s set dither correctly */
+ if (!IS_I965G(dev)) {
+ if (dev_priv->panel_wants_dither || dev_priv->lvds_dither)
+ pfit_control |= PANEL_8TO6_DITHER_ENABLE;
+ }
+
+ /* Native modes don't need fitting */
+ if (adjusted_mode->hdisplay == mode->hdisplay &&
+ adjusted_mode->vdisplay == mode->vdisplay) {
+ pfit_pgm_ratios = 0;
+
[Resend] [Intel-gfx] [PATCH 2/3] parse general definition block to get the SDVO device info
The general definition block contains the child device tables, which include
the child device info. For example: device slave address, device dvo port,
device type.
We will get the info of SDVO device by parsing the general definition blocks.
Only when a valid slave address is found, it is regarded as the SDVO device.
And the info of DVO port and slave address is recorded.
http://bugs.freedesktop.org/show_bug.cgi?id=20429
Signed-off-by: Zhao Yakui
---
src/i830.h |8 -
src/i830_bios.c | 81
2 files changed, 88 insertions(+), 1 deletion(-)
Index: xf86_video_intel/src/i830_bios.c
===
--- xf86_video_intel.orig/src/i830_bios.c 2009-06-08 09:57:38.0
+0800
+++ xf86_video_intel/src/i830_bios.c2009-06-08 10:08:17.0 +0800
@@ -47,6 +47,8 @@
(bios[_addr + 2] << 16) | \
(bios[_addr + 3] << 24))
+#defineSLAVE_ADDR1 0x70
+#defineSLAVE_ADDR2 0x72
static void *
find_section(struct bdb_header *bdb, int section_id)
{
@@ -236,6 +238,84 @@
pI830->integrated_lvds = FALSE;
}
+static
+void parse_sdvo_mapping(ScrnInfoPtr pScrn, struct bdb_header *bdb)
+{
+unsigned int block_size;
+uint16_t *block_ptr;
+struct bdb_general_definitions *defs;
+struct child_device_config *child;
+int i, child_device_num, count;
+struct sdvo_device_mapping *p_mapping;
+I830Ptr pI830 = I830PTR(pScrn);
+
+defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
+if (!defs) {
+ xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+ "can't find the general definition blocks\n");
+ return;
+}
+/* Get the block size of general defintion block */
+block_ptr = (uint16_t *)((char *)defs - 2);
+block_size = *block_ptr;
+child_device_num = (block_size - sizeof(*defs)) / sizeof(*child);
+count = 0;
+
+for (i = 0; i < child_device_num; i++) {
+ child = &defs->devices[i];
+ if (!child->device_type) {
+ /* skip invalid child device type*/
+continue;
+ }
+ if (child->slave_addr == SLAVE_ADDR1 ||
+ child->slave_addr == SLAVE_ADDR2) {
+ if (child->dvo_port != DEVICE_PORT_DVOB &&
+ child->dvo_port != DEVICE_PORT_DVOC) {
+ /* skip the incorrect sdvo port */
+ xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+ "Incorrect SDVO port\n");
+ continue;
+ }
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "the SDVO device with slave addr %x "
+ "is found on DVO %x port\n",
+ child->slave_addr, child->dvo_port);
+ /* fill the primary dvo port */
+ p_mapping = &(pI830->sdvo_mappings[child->dvo_port - 1]);
+ if (!p_mapping->initialized) {
+ p_mapping->dvo_port = child->dvo_port;
+ p_mapping->dvo_wiring = child->dvo_wiring;
+ p_mapping->initialized = 1;
+ p_mapping->slave_addr = child->slave_addr;
+ } else {
+ xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+ "One DVO port is shared by two slave "
+ "address. Maybe it can't be handled\n");
+ }
+ /* If there exists the slave2_addr, maybe it is a sdvo
+* device that contain multiple inputs. And it can't
+* handled by SDVO driver.
+* Ignore the dvo mapping of slave2_addr
+* of course its mapping info won't be added.
+*/
+ if (child->slave2_addr) {
+ xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+ "Two DVO ports uses the same slave address."
+ "Maybe it can't be handled by SDVO driver\n");
+ }
+ count++;
+ } else {
+ /* if the slave address is neither 0x70 nor 0x72, skip it. */
+ continue;
+ }
+}
+/* If the count is zero, it indicates that no sdvo device is found */
+if (!count)
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "No SDVO device is found in VBT\n");
+
+return;
+}
#define INTEL_VBIOS_SIZE (64 * 1024) /* XXX */
/**
@@ -302,6 +382,7 @@
parse_general_features(pI830, bdb);
parse_panel_data(pI830, bdb);
parse_driver_feature(pI830, bdb);
+parse_sdvo_mapping(pScrn, bdb);
xfree(bios);
Index: xf86_video_intel/src/i830.h
===
--- xf86_video_intel.orig/src/i830.h2009-06-08 09:57:38.0 +0800
+++ xf86_video_intel/src/i830.h 2009-06-08 10:08:17.0 +0800
@@ -328,7 +328,12 @@
DRI_NONE,
DRI_DRI2
};
-
+struct sdvo_
[Bug 10561] SecondLife client hangs at startup with r300
http://bugs.freedesktop.org/show_bug.cgi?id=10561 --- Comment #31 from Michel Dänzer 2009-06-08 03:16:24 PST --- (In reply to comment #29) > Can you reproduce it with current master or radeon-rewrite branch of mesa? Mesa doesn't matter for this... Looking at compat_radeon_cp_texture() in drivers/gpu/drm/radeon/radeon_ioc32.c in a recent kernel tree, there still isn't anything after the drm_ioctl() call, so this can't really be fixed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13485] New: Console uses less than full resolution
http://bugzilla.kernel.org/show_bug.cgi?id=13485 Summary: Console uses less than full resolution Product: Drivers Version: 2.5 Kernel Version: v2.6.30-rc8-5-gc9fb15f Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: br...@xyzw.org CC: airl...@linux.ie, kei...@keithp.com Regression: Yes Created an attachment (id=21805) --> (http://bugzilla.kernel.org/attachment.cgi?id=21805) dmesg output I have a laptop with i965 graphics and a 1280x800 display. Up until a certain commit, the KMS framebuffer filled the whole screen at native resolution. Since this commit, the console fills only a 1024x768 area, anchored to the top left corner, leaving blank the right and bottom edges of the screen. usplash also runs at 1024x768. X still uses 1280x800, however. The console appears to be picking a resolution to accommodate the TV out, according to the following in dmesg: [1.217492] allocated 1280x800 fb: 0x007df000, bo 88013e6d2540 [1.279983] [drm] TV-13: set mode 1024x768 18 [1.360854] [drm] LVDS-8: set mode 1280x800 15 [1.645634] Console: switching to colour frame buffer device 128x48 [1.648155] fb0: inteldrmfb frame buffer device No TV is connected, and xrandr correctly reports 'TV1 disconnected'. I assume that the TV out should be irrelevant in picking the console resolution, then. The problem appears with this commit: commit c9fb15f60eb517c958dec64dca9357bf62bf2201 Author: Keith Packard Date: Sat May 30 20:42:28 2009 -0700 drm: Hook up DPMS property handling in drm_crtc.c. Add drm_helper_connector_dpms. Making the drm_crtc.c code recognize the DPMS property and invoke the connector->dpms function doesn't remove any capability from the driver while reducing code duplication. That just highlighted the problem with the existing DPMS functions which could turn off the connector, but failed to turn off any relevant crtcs. The new drm_helper_connector_dpms function manages all of that, using the drm_helper-specific crtc and encoder dpms functions, automatically computing the appropriate DPMS level for each object in the system. This fixes the current troubles in the i915 driver which left PLLs, pipes and planes running while in DPMS_OFF mode or even while they were unused. Signed-off-by: Keith Packard Signed-off-by: Dave Airlie -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
