Re: [PATCH] make the drm (linux) obey device classes + nouveau detection without pci-id's
Here it is.
Maarten.
On 10/2/07, Maarten Maathuis <[EMAIL PROTECTED]> wrote:
> You seem to be correct, i must have added the tmp variable in attempt
> to solve something, that i ended up solving differently.
>
> I will redo the patch and send again.
>
> Maarten.
>
> On 10/2/07, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Maarten Maathuis wrote:
> > > Please check the first patch, the second is only to give you an idea
> > > why i would want this. Only implemented for linux, since i lack a bsd
> > > system.
> > >
> > > Anything wrong with this?
> >
> >
> > I guess I don't understand the need for the extra pdev_tmp variable.
> > Couldn't you get the same result by just adding the following at the
> > head of the loop?
> >
> > if ((pid->class != 0)
> > && ((pdev->class & pid->class_mask) != pid->class)) {
> > continue;
> > }
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.7 (GNU/Linux)
> >
> > iD8DBQFHAp6qX1gOwKyEAw8RAvJjAJ0X1M8jcnltRxj0h9sZZx1L2sXi4gCfTHlR
> > vU+ZkjghLs4x/2Al41Q+DF8=
> > =eowq
> > -END PGP SIGNATURE-
> >
>
From 014c78d6e63f0f715cdca2d33e3c0c4aa1c62370 Mon Sep 17 00:00:00 2001
From: Maarten Maathuis <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 21:54:37 +0200
Subject: [PATCH] linux-drm: Obey device class requirements when detecting devices.
---
linux-core/drm_drv.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index 7359889..a09fa96 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -321,6 +321,11 @@ int drm_init(struct drm_driver *driver,
while ((pdev =
pci_get_subsys(pid->vendor, pid->device, pid->subvendor,
pid->subdevice, pdev))) {
+ /* Are there device class requirements? */
+ if ((pid->class != 0)
+&& ((pdev->class & pid->class_mask) != pid->class)) {
+continue;
+ }
/* is there already a driver loaded, or (short circuit saves work) */
/* does something like VesaFB have control of the memory region? */
if (pci_dev_driver(pdev)
@@ -347,6 +352,11 @@ int drm_init(struct drm_driver *driver,
pci_get_subsys(pid->vendor, pid->device,
pid->subvendor, pid->subdevice,
pdev))) {
+/* Are there device class requirements? */
+if ((pid->class != 0)
+ && ((pdev->class & pid->class_mask) != pid->class)) {
+ continue;
+}
/* stealth mode requires a manual probe */
pci_dev_get(pdev);
if ((rc = drm_get_dev(pdev, &pciidlist[i], driver))) {
--
1.5.3.3
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] make the drm (linux) obey device classes + nouveau detection without pci-id's
You seem to be correct, i must have added the tmp variable in attempt
to solve something, that i ended up solving differently.
I will redo the patch and send again.
Maarten.
On 10/2/07, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Maarten Maathuis wrote:
> > Please check the first patch, the second is only to give you an idea
> > why i would want this. Only implemented for linux, since i lack a bsd
> > system.
> >
> > Anything wrong with this?
>
>
> I guess I don't understand the need for the extra pdev_tmp variable.
> Couldn't you get the same result by just adding the following at the
> head of the loop?
>
> if ((pid->class != 0)
> && ((pdev->class & pid->class_mask) != pid->class)) {
> continue;
> }
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (GNU/Linux)
>
> iD8DBQFHAp6qX1gOwKyEAw8RAvJjAJ0X1M8jcnltRxj0h9sZZx1L2sXi4gCfTHlR
> vU+ZkjghLs4x/2Al41Q+DF8=
> =eowq
> -END PGP SIGNATURE-
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] make the drm (linux) obey device classes + nouveau detection without pci-id's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maarten Maathuis wrote:
> Please check the first patch, the second is only to give you an idea
> why i would want this. Only implemented for linux, since i lack a bsd
> system.
>
> Anything wrong with this?
I guess I don't understand the need for the extra pdev_tmp variable.
Couldn't you get the same result by just adding the following at the
head of the loop?
if ((pid->class != 0)
&& ((pdev->class & pid->class_mask) != pid->class)) {
continue;
}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHAp6qX1gOwKyEAw8RAvJjAJ0X1M8jcnltRxj0h9sZZx1L2sXi4gCfTHlR
vU+ZkjghLs4x/2Al41Q+DF8=
=eowq
-END PGP SIGNATURE-
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)
On Tuesday, October 2, 2007 10:49 am Philippe Gaultier wrote: > 2007/10/2, Jesse Barnes <[EMAIL PROTECTED]>: > > On Tuesday, October 2, 2007 8:28 am Philippe Gaultier wrote: > > > Oct 2 00:32:18 coreduo i2c-adapter i2c-4: sendbytes: error - > > > bailout. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to > > > read EDID block. > Oct 2 00:32:19 coreduo i915 :00:02.0: > > > TMDS-1: no EDID data > > > > This is probably the first thing to fix. Can you play with the i2c > > timings and see if you can get it to return some EDID data? The X > > server has some i2c code you can look at, as does the Intel DDX > > driver. It's probably a timing issue, but may also be an i2c setup > > problem in intel_sdvo.c (check against the DDX driver's i830_sdvo.c > > file to see what might be missing). > > Can you tell me which file I should check in order to not break the > whole drm-modesetting driver ? > > I think it should be : > > - intel_i2c.c > - drm_edid.c > and perhaps > - drm_crtc.c > > but I need your advice on this. intel_i2c.c has the i2c timings and get/set routines, so it's a good start. drm_edid.c probably isn't very interesting in this case--it just takes the EDID blob and turns it into its constituent modes and monitor info structures. Likewise, drm_crtc.c probably won't help in this case, it just handles all the metadata allocation and initialization. So your best bet is intel_i2c.c and intel_sdvo.c since you have an HDMI attached display. Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)
2007/10/2, Jesse Barnes <[EMAIL PROTECTED]>: > On Tuesday, October 2, 2007 8:28 am Philippe Gaultier wrote: > > Oct 2 00:32:18 coreduo i2c-adapter i2c-4: sendbytes: error - > > bailout. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read > > EDID block. > Oct 2 00:32:19 coreduo i915 :00:02.0: TMDS-1: no > > EDID data > > This is probably the first thing to fix. Can you play with the i2c > timings and see if you can get it to return some EDID data? The X > server has some i2c code you can look at, as does the Intel DDX driver. > It's probably a timing issue, but may also be an i2c setup problem in > intel_sdvo.c (check against the DDX driver's i830_sdvo.c file to see > what might be missing). > Can you tell me which file I should check in order to not break the whole drm-modesetting driver ? I think it should be : - intel_i2c.c - drm_edid.c and perhaps - drm_crtc.c but I need your advice on this. Thank you Philippe > Thanks, > Jesse > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] make the drm (linux) obey device classes + nouveau detection without pci-id's
Has anyone looked at this? On 10/1/07, Maarten Maathuis <[EMAIL PROTECTED]> wrote: > Please check the first patch, the second is only to give you an idea > why i would want this. Only implemented for linux, since i lack a bsd > system. > > Anything wrong with this? > > Sincerely, > > Maarten Maathuis. > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)
On Tuesday, October 2, 2007 8:28 am Philippe Gaultier wrote: > Oct 2 00:32:18 coreduo i2c-adapter i2c-4: sendbytes: error - > bailout. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read > EDID block. > Oct 2 00:32:19 coreduo i915 :00:02.0: TMDS-1: no > EDID data This is probably the first thing to fix. Can you play with the i2c timings and see if you can get it to return some EDID data? The X server has some i2c code you can look at, as does the Intel DDX driver. It's probably a timing issue, but may also be an i2c setup problem in intel_sdvo.c (check against the DDX driver's i830_sdvo.c file to see what might be missing). Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12646] Wrong colors using yuy2 and uyvy with radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=12646 --- Comment #3 from [EMAIL PROTECTED] 2007-10-02 10:07 PST --- Created an attachment (id=11864) --> (http://bugs.freedesktop.org/attachment.cgi?id=11864&action=view) output of glxinfo I tried mesa from git (http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary) with the same result. Is there anything else I can try or supply as debug info? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
i945GM / drm-modesetting-101 vs Xorg (Xorg : 1 / drm-modesetting-101 : 0, 5) :-)
Hi, I have an intel abit IL90MV mother board : - i945GM chipset - intel core2duo t5600 - 1Gb RAM The mobo is connected through HDMI to a samsung PDP which is HDReady (1280x720p and 1920x1080i). I want to thank you for the big work you are doing on those drivers and to tell you that I understand the code is "bleeding edge code". I just want to give you some feedback about what's going on with my hardware. If you need me to make some more tests, just let me know I'll do my best to help you. Distro : gentoo "stable" uptodate you can find the lscpi at the end of the mail. currently I'm using Xorg + Xrandr to display video through my HDMI output (aka TMDS-1) Except some little problems under X (some synchro error and some tearing @ 1280x720) everything seems to work fine. I'm trying to remove the whole XOrg server to replace it by a framebuffer. Since I have an intel graphic card (GMA950) I'm trying to use the the drm-modesetting-101 branch to have a correct output (1280x720). For the moment, I was not able to make it work. Here is the whole story : Xorg : some output of the Xorg.log (will be usefull later) Xorg probe all the outputs of the 945GM : the interesting one is TMDS-1 -- 8< -- TMDS-1 Probe by Xorg -- 8< -- ... (II) intel(0): EDID for output TMDS-1 (II) intel(0): Manufacturer: SAM Model: 25b Serial#: 0 (II) intel(0): Year: 2006 Week: 20 (II) intel(0): EDID Version: 1.3 (II) intel(0): Digital Display Input (II) intel(0): Max H-Image Size [cm]: horiz.: 16 vert.: 9 (II) intel(0): Gamma: 2.20 (II) intel(0): No DPMS capabilities specified; RGB/Color Display (II) intel(0): First detailed timing is preferred mode (II) intel(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 (II) intel(0): blueX: 0.150 blueY: 0.060 whiteX: 0.312 whiteY: 0.329 (II) intel(0): Supported VESA Video Modes: (II) intel(0): [EMAIL PROTECTED] (II) intel(0): Manufacturer's mask: 0 (II) intel(0): Supported additional Video Mode: (II) intel(0): clock: 74.2 MHz Image Size: 160 x 90 mm (II) intel(0): h_active: 1280 h_sync: 1720 h_sync_end 1760 h_blank_end 1980 h_border: 0 (II) intel(0): v_active: 720 v_sync: 725 v_sync_end 730 v_blanking: 750 v_border: 0 (II) intel(0): Supported additional Video Mode: (II) intel(0): clock: 74.2 MHz Image Size: 160 x 90 mm (II) intel(0): h_active: 1920 h_sync: 2448 h_sync_end 2492 h_blank_end 2640 h_border: 0 (II) intel(0): v_active: 540 v_sync: 542 v_sync_end 547 v_blanking: 562 v_border: 0 (II) intel(0): Ranges: V min: 50 V max: 65 Hz, H min: 28 H max: 48 kHz, PixClock max 80 MHz (II) intel(0): Monitor name: SAMSUNG PDP (II) intel(0): Number of EDID sections to follow: 1 (II) intel(0): EDID (in hex): (II) intel(0): 00004c2d5b02 (II) intel(0): 14100103801009780aee91a3544c9926 (II) intel(0): 0f50542001010101010101010101 (II) intel(0): 010101010101011d00bc52d01e20b828 (II) intel(0): 5540a05a001e011d80d0721c1620 (II) intel(0): 102c2580a05a009e00fd0032 (II) intel(0): 411c3008000a20202020202000fc (II) intel(0): 0053414d53554e47205044500a200140 (II) intel(0): EDID vendor "SAM", prod id 603 ... (II) intel(0): Printing probed modes for output TMDS-1 (II) intel(0): Modeline "1280x720"x50.0 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync (37.5 kHz) (II) intel(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) ... (II) intel(0): Output TMDS-1 connected ... (II) intel(0): Output TMDS-1 using initial mode 1280x720 -- 8< -- Once Xorg has been initilised I use Xrandr to finish the hardware set up : -- 8< -- xrandr --output TMDS-1 --preferred xrandr --output LVDS --off -- 8< -- Everything works like a charm. Now, about the DRM modesetting stuff Yesterday I tried to set up the drm / intelfb by checking out the latest git modesetting-101. Compilation works fine, initialisation seems ok except that EDID Probe does not work : -- 8< -- DRM Probe -- 8< -- Oct 2 00:32:12 coreduo [drm] Initialized drm 1.1.0 20060810 Oct 2 00:32:17 coreduo PCI: Setting latency timer of device :00:02.0 to 64 Oct 2 00:32:17 coreduo setting up 8122368 bytes of VRAM space Oct 2 00:32:17 coreduo setting up 260313088 bytes of TT space Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read EDID block. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read EDID block. Oct 2 00:32:18 coreduo i2c-adapter i2c-4: unable to read EDID block. Oct 2 00:32:18 coreduo i915 :00:02.0: LVDS: no EDID data Oct 2 00:32:18 coreduo (SDVO_CMD_GET_DEVICE_CAPS) Oct 2 00:32:18 coreduo 04 AC 00 01 01 01 01 00 (Success) Oct 2 00:32:18 coreduo 00 (SDVO_CMD_SET_TARGET_INPUT) Oct 2 00:32:18 coreduo (Success) Oct 2 00:32:18 coreduo (SDVO_CMD_GET_INPUT_PIXEL_CLOCK_RANGE) Oct 2 00:32:18 coreduo C4 09 74 40 (Success) Oct 2 00:32:18 coreduo (SDVO_CMD_GET_ATTACHED_DISPLAYS) Oct 2 00:32:18 coreduo 01 00 (Success) Oct 2 00:32:18 coreduo 02 (SDVO_CMD_SET_CONTROL_B
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
http://bugs.freedesktop.org/show_bug.cgi?id=8357 --- Comment #6 from [EMAIL PROTECTED] 2007-10-02 08:27 PST --- After plugin hw and testing myself rendering doesn't work properly without this offset. Investigation on why this is needed would help to remove this and so move the limit to 4096. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
http://bugs.freedesktop.org/show_bug.cgi?id=8357 --- Comment #5 from [EMAIL PROTECTED] 2007-10-02 08:16 PST --- Forgot to say that you need to remove this in r300_cmdbuf.c in drm. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
http://bugs.freedesktop.org/show_bug.cgi?id=8357 --- Comment #4 from [EMAIL PROTECTED] 2007-10-02 08:15 PST --- I believe r300 should be able to do 3d rendering in buffer with width up to 4096. To test this please remove all "+ R300_CLIPRECT_OFFSET" which should help and fix problem you see. Please report if so. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12646] Wrong colors using yuy2 and uyvy with radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=12646 --- Comment #2 from [EMAIL PROTECTED] 2007-10-02 02:15 PST --- Ahh, I'm not familiar with the 3d stack at all I must admit. I'm using mesa-7.0.1. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12646] Wrong colors using yuy2 and uyvy with radeon driver
http://bugs.freedesktop.org/show_bug.cgi?id=12646 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] Component|Driver/Radeon |Drivers/DRI/r300 Product|xorg|Mesa QAContact|[EMAIL PROTECTED] | --- Comment #1 from [EMAIL PROTECTED] 2007-10-02 00:37 PST --- glimagesink uses the Mesa driver. It's working fine here with the r300 driver from Mesa Git, which version are you using? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
