git repos, r600g prerequites
Am 18.11.2010 15:34, schrieb Jerome Glisse: > Best is to use mesa master repository. And kernel 2.6.36 or newer, the > other drm kernel tree are mostly to fix issues and are interesting if > you are facing one of those issues or just want to help in testing > drm. Just a quick follow-up: current drm git trees and 2.6.37-1 from ubuntu kernel-ppa don't work, glxgears crashes horribly including an instant system reset. 2.6.36 from kernel-ppa does work. Regards Marius
Re: git repos, r600g prerequites
Am 18.11.2010 15:34, schrieb Jerome Glisse: Best is to use mesa master repository. And kernel 2.6.36 or newer, the other drm kernel tree are mostly to fix issues and are interesting if you are facing one of those issues or just want to help in testing drm. Just a quick follow-up: current drm git trees and 2.6.37-1 from ubuntu kernel-ppa don't work, glxgears crashes horribly including an instant system reset. 2.6.36 from kernel-ppa does work. Regards Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
git repos, r600g prerequites
Hi, I find the various git repositories for drm sometimes a little confusing. For example, what is the difference between d-n and d-c-n? Maybe it would be a good idea to fill out the gitweb information for each each repository. Currently they all report "Unnamed repository; edit this file to name it for gitweb." I'm asking because I want to know which repo would be suited best to try r600g. I'm on an RS780G and have the xorg-edgers X and mesa packages, x86_64. About half a year ago LIBGL_DRIVERS_DIR=/usr/lib/dri/gallium glxgears used to work, but for a while know this will instantly and horribly corrupt the screen, crash the system, and reboot. So I would like to make sure I'm using the right drm base for my experiments. I would also be interested in any other prerequites r600g requires. TIA Marius
git repos, r600g prerequites
Hi, I find the various git repositories for drm sometimes a little confusing. For example, what is the difference between d-n and d-c-n? Maybe it would be a good idea to fill out the gitweb information for each each repository. Currently they all report Unnamed repository; edit this file to name it for gitweb. I'm asking because I want to know which repo would be suited best to try r600g. I'm on an RS780G and have the xorg-edgers X and mesa packages, x86_64. About half a year ago LIBGL_DRIVERS_DIR=/usr/lib/dri/gallium glxgears used to work, but for a while know this will instantly and horribly corrupt the screen, crash the system, and reboot. So I would like to make sure I'm using the right drm base for my experiments. I would also be interested in any other prerequites r600g requires. TIA Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM: ignore invalid EDID extensions
On 28.10.2010 11:12, wrote sam tygier: > Without this patch i get no display (X or VT) on myEIZO S2242W monitor > when using KMS > > This was discussed back in september, this is the second version of the > patch based on ajax's comments. i have opened a bug for the issue: > https://bugs.freedesktop.org/show_bug.cgi?id=31154 Might this even be a cure for the bug in recent drm that ignores all 50Hz modes? The patch looks like that--without it--there isn't even an error displayed upon hitting a bad EDID record. I'm sorry I can't try this out at the moment though. Regards, Marius
Re: [PATCH] DRM: ignore invalid EDID extensions
On 28.10.2010 11:12, wrote sam tygier: Without this patch i get no display (X or VT) on myEIZO S2242W monitor when using KMS This was discussed back in september, this is the second version of the patch based on ajax's comments. i have opened a bug for the issue: https://bugs.freedesktop.org/show_bug.cgi?id=31154 Might this even be a cure for the bug in recent drm that ignores all 50Hz modes? The patch looks like that--without it--there isn't even an error displayed upon hitting a bad EDID record. I'm sorry I can't try this out at the moment though. Regards, Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't enable underscan with interlaced modes
Am 22.09.2010 06:40, schrieb Alex Deucher: > 2010/9/21 Marius Gr?ger: >> On 10.09.2010 17:20 Alex Deucher wrote: >>> >>> The scaler doesn't appear to work with interlaced modes as you've >>> noticed; I don't off hand know whether it can be made to or not. >>> Unfortunately, I won't have time to dig into this more for a while. >> >> Is there public documentation available wrt this matter? www.x.org/docs/AMD/ >> appears to focus on 3D stuff primarily... >> > > Not at the moment, however, you could implement underscan using the 3D > engine to do the scaling rather than the display scalers. I think you > could even do it with randr crtc transforms (which use the 3d engine). Are you referring to xrandr --transpose? At least for me this seems to be only partially implemented. For example: xrandr --output HDMI-0 --mode 1920x1080 at 50i --transform 0.5,0,0,0,0.5,0,0,0,1 This does in fact render the image scaled down by 50%. However, xrandr --verbose yields: HDMI-0 connected 1920x1080+0+0 (0xfd) normal (normal left inverted right x axis y axis) 1600mm x 900mm ... Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 Translation doesn't work at all, so it's not a viable workaround. Sigh. This is all kind of frustrating... Regards, Marius
Re: [PATCH] drm/radeon/kms: don't enable underscan with interlaced modes
Am 22.09.2010 06:40, schrieb Alex Deucher: 2010/9/21 Marius Grögermarius.groe...@googlemail.com: On 10.09.2010 17:20 Alex Deucher wrote: The scaler doesn't appear to work with interlaced modes as you've noticed; I don't off hand know whether it can be made to or not. Unfortunately, I won't have time to dig into this more for a while. Is there public documentation available wrt this matter? www.x.org/docs/AMD/ appears to focus on 3D stuff primarily... Not at the moment, however, you could implement underscan using the 3D engine to do the scaling rather than the display scalers. I think you could even do it with randr crtc transforms (which use the 3d engine). Are you referring to xrandr --transpose? At least for me this seems to be only partially implemented. For example: xrandr --output HDMI-0 --mode 1920x1...@50i --transform 0.5,0,0,0,0.5,0,0,0,1 This does in fact render the image scaled down by 50%. However, xrandr --verbose yields: HDMI-0 connected 1920x1080+0+0 (0xfd) normal (normal left inverted right x axis y axis) 1600mm x 900mm ... Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 Translation doesn't work at all, so it's not a viable workaround. Sigh. This is all kind of frustrating... Regards, Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't enable underscan with interlaced modes
On 10.09.2010 17:20 Alex Deucher wrote: > The scaler doesn't appear to work with interlaced modes as you've > noticed; I don't off hand know whether it can be made to or not. > Unfortunately, I won't have time to dig into this more for a while. Is there public documentation available wrt this matter? www.x.org/docs/AMD/ appears to focus on 3D stuff primarily... Regards, Marius
[PATCH] Add drm properties to configure the width of the underscan borders
This allows for a more exact fitting on the physical
display. The new properties default to zero which corresponds to the
previous underscan border width[height] formula:
(display_width[display_width] >> 5) + 16.
Example to set a horizontal border width of 30 and a vertikal border
height of 22:
xrandr --output HDMI-0 --set underscan on --set "underscan hborder" 30 --set
"underscan vborder" 22
Signed-off-by: Marius Gr?ger
---
drivers/gpu/drm/radeon/radeon_connectors.c | 55 ++--
drivers/gpu/drm/radeon/radeon_display.c| 28 +-
drivers/gpu/drm/radeon/radeon_mode.h |4 ++
3 files changed, 82 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 1a5ee39..12ec609 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -326,6 +326,34 @@ int radeon_connector_set_property(struct drm_connector
*connector, struct drm_pr
}
}
+ if (property == rdev->mode_info.underscan_hborder_property) {
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ if (radeon_encoder->underscan_hborder != val) {
+ radeon_encoder->underscan_hborder = val;
+ radeon_property_change_mode(_encoder->base);
+ }
+ }
+
+ if (property == rdev->mode_info.underscan_vborder_property) {
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ if (radeon_encoder->underscan_vborder != val) {
+ radeon_encoder->underscan_vborder = val;
+ radeon_property_change_mode(_encoder->base);
+ }
+ }
+
if (property == rdev->mode_info.tv_std_property) {
encoder = radeon_find_encoder(connector,
DRM_MODE_ENCODER_TVDAC);
if (!encoder) {
@@ -1142,10 +1170,17 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_connector_attach_property(_connector->base,
rdev->mode_info.coherent_mode_property,
1);
- if (ASIC_IS_AVIVO(rdev))
+ if (ASIC_IS_AVIVO(rdev)) {
drm_connector_attach_property(_connector->base,
rdev->mode_info.underscan_property,
UNDERSCAN_AUTO);
+ drm_connector_attach_property(_connector->base,
+
rdev->mode_info.underscan_hborder_property,
+ 0);
+ drm_connector_attach_property(_connector->base,
+
rdev->mode_info.underscan_vborder_property,
+ 0);
+ }
if (connector_type == DRM_MODE_CONNECTOR_DVII) {
radeon_connector->dac_load_detect = true;
drm_connector_attach_property(_connector->base,
@@ -1170,10 +1205,17 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_connector_attach_property(_connector->base,
rdev->mode_info.coherent_mode_property,
1);
- if (ASIC_IS_AVIVO(rdev))
+ if (ASIC_IS_AVIVO(rdev)) {
drm_connector_attach_property(_connector->base,
rdev->mode_info.underscan_property,
UNDERSCAN_AUTO);
+ drm_connector_attach_property(_connector->base,
+
rdev->mode_info.underscan_hborder_property,
+ 0);
+ drm_connector_attach_property(_connector->base,
+
rdev->mode_info.underscan_vborder_property,
+ 0);
+ }
subpixel_order = SubPixelHorizontalRGB;
break;
case DRM_MODE_CONNECTOR_DisplayPort:
@@ -1201,10 +1243,17 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_connector_attach_property(_connector->base,
[PATCH] Add drm properties to configure the width of the underscan borders
This allows for a more exact fitting on the physical
display. The new properties default to zero which corresponds to the
previous underscan border width[height] formula:
(display_width[display_width] 5) + 16.
Example to set a horizontal border width of 30 and a vertikal border
height of 22:
xrandr --output HDMI-0 --set underscan on --set underscan hborder 30 --set
underscan vborder 22
Signed-off-by: Marius Gröger marius.groe...@googlemail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c | 55 ++--
drivers/gpu/drm/radeon/radeon_display.c| 28 +-
drivers/gpu/drm/radeon/radeon_mode.h |4 ++
3 files changed, 82 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 1a5ee39..12ec609 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -326,6 +326,34 @@ int radeon_connector_set_property(struct drm_connector
*connector, struct drm_pr
}
}
+ if (property == rdev-mode_info.underscan_hborder_property) {
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ if (radeon_encoder-underscan_hborder != val) {
+ radeon_encoder-underscan_hborder = val;
+ radeon_property_change_mode(radeon_encoder-base);
+ }
+ }
+
+ if (property == rdev-mode_info.underscan_vborder_property) {
+ /* need to find digital encoder on connector */
+ encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TMDS);
+ if (!encoder)
+ return 0;
+
+ radeon_encoder = to_radeon_encoder(encoder);
+
+ if (radeon_encoder-underscan_vborder != val) {
+ radeon_encoder-underscan_vborder = val;
+ radeon_property_change_mode(radeon_encoder-base);
+ }
+ }
+
if (property == rdev-mode_info.tv_std_property) {
encoder = radeon_find_encoder(connector,
DRM_MODE_ENCODER_TVDAC);
if (!encoder) {
@@ -1142,10 +1170,17 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_connector_attach_property(radeon_connector-base,
rdev-mode_info.coherent_mode_property,
1);
- if (ASIC_IS_AVIVO(rdev))
+ if (ASIC_IS_AVIVO(rdev)) {
drm_connector_attach_property(radeon_connector-base,
rdev-mode_info.underscan_property,
UNDERSCAN_AUTO);
+ drm_connector_attach_property(radeon_connector-base,
+
rdev-mode_info.underscan_hborder_property,
+ 0);
+ drm_connector_attach_property(radeon_connector-base,
+
rdev-mode_info.underscan_vborder_property,
+ 0);
+ }
if (connector_type == DRM_MODE_CONNECTOR_DVII) {
radeon_connector-dac_load_detect = true;
drm_connector_attach_property(radeon_connector-base,
@@ -1170,10 +1205,17 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_connector_attach_property(radeon_connector-base,
rdev-mode_info.coherent_mode_property,
1);
- if (ASIC_IS_AVIVO(rdev))
+ if (ASIC_IS_AVIVO(rdev)) {
drm_connector_attach_property(radeon_connector-base,
rdev-mode_info.underscan_property,
UNDERSCAN_AUTO);
+ drm_connector_attach_property(radeon_connector-base,
+
rdev-mode_info.underscan_hborder_property,
+ 0);
+ drm_connector_attach_property(radeon_connector-base,
+
rdev-mode_info.underscan_vborder_property,
+ 0);
+ }
subpixel_order = SubPixelHorizontalRGB;
break;
case DRM_MODE_CONNECTOR_DisplayPort:
@@ -1201,10 +1243,17 @@ radeon_add_atom_connector(struct drm_device *dev
Re: [PATCH] drm/radeon/kms: don't enable underscan with interlaced modes
On 10.09.2010 17:20 Alex Deucher wrote: The scaler doesn't appear to work with interlaced modes as you've noticed; I don't off hand know whether it can be made to or not. Unfortunately, I won't have time to dig into this more for a while. Is there public documentation available wrt this matter? www.x.org/docs/AMD/ appears to focus on 3D stuff primarily... Regards, Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
video= semantics changed?
I sent this message during the weekend and I'm afraid it might got lost during people's monday morning inbox purging ;-) Seriously, I'd be grateful for any insights on that matter which keeps me from moving on to 2.6.36... Thanks Marius Original Message Date: Sat, 11 Sep 2010 13:20:22 +0200 With the latest d-r-t my grub cmdline option video=1280x720 at 50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 4 weeks ago works and correctly uses the EDID reported 1280x720 at 50 mode. Does anyone know what might have happened to the video= code? I also tried video=1280x720R at 50, but that didn't work either. X works fine though. Thanks Marius
video= semantics changed?
I sent this message during the weekend and I'm afraid it might got lost during people's monday morning inbox purging ;-) Seriously, I'd be grateful for any insights on that matter which keeps me from moving on to 2.6.36... Thanks Marius Original Message Date: Sat, 11 Sep 2010 13:20:22 +0200 With the latest d-r-t my grub cmdline option video=1280x...@50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 4 weeks ago works and correctly uses the EDID reported 1280x...@50 mode. Does anyone know what might have happened to the video= code? I also tried video=1280x7...@50, but that didn't work either. X works fine though. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
video= semantics changed?
With the latest d-r-t my grub cmdline option video=1280x720 at 50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 4 weeks ago works and correctly uses the EDID reported 1280x720 at 50 mode. Does anyone know what might have happened to the video= code? I also tried video=1280x720R at 50, but that didn't work either. X works fine though. Thanks Marius
video= semantics changed?
With the latest d-r-t my grub cmdline option video=1280x...@50 no longer works (RS780, output to LCD TV via HDMI). The fbcon apparently is enabled, but the TV doen't get a displayable picture anymore. Booting with d-r-t from 4 weeks ago works and correctly uses the EDID reported 1280x...@50 mode. Does anyone know what might have happened to the video= code? I also tried video=1280x7...@50, but that didn't work either. X works fine though. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't enable underscan with interlaced modes
On 10.09.2010 09:19, wrote Alex Deucher: > They aren't compatible. Hm, ok. Is this supposed to be quick fix or is there any chance to get proper underscan for interlaced modes? Secondly, have you had a chance to look at my register dumps? Any clues as to why the Xserver prunes interlaced modes only with KMS? Thanks Marius
Interlace modes with r600 KMS
On Thu, 9 Sep 2010 11:03:54 -0400 wrote Alex Deucher : > Does disabling underscan fix interlaced? Yes, without underscan I can switch to my manually defined interlace mode and it looks ok. However, the EDID reported interlace modes are still pruned by the Xserver, so there still seems to be a subtle difference between KMS and UMS. Thanks Marius
Re: Interlace modes with r600 KMS
On Thu, 9 Sep 2010 11:03:54 -0400 wrote Alex Deucher alexdeuc...@gmail.com: Does disabling underscan fix interlaced? Yes, without underscan I can switch to my manually defined interlace mode and it looks ok. However, the EDID reported interlace modes are still pruned by the Xserver, so there still seems to be a subtle difference between KMS and UMS. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: don't enable underscan with interlaced modes
On 10.09.2010 09:19, wrote Alex Deucher: They aren't compatible. Hm, ok. Is this supposed to be quick fix or is there any chance to get proper underscan for interlaced modes? Secondly, have you had a chance to look at my register dumps? Any clues as to why the Xserver prunes interlaced modes only with KMS? Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Interlace modes with r600 KMS
Am 09.09.2010 17:03, schrieb Alex Deucher: > Does disabling underscan fix interlaced? I just pulled the latest d-r-t and at least I can confirm that the problem is present without any of my tinkerings :-) I still need to check with underscan disabled. There is no cmdline option for this yet, is there? What's the quickest way to disable underscan, replace UNDERSCAN_AUTO with UNDERSCAN_OFF? Regards Marius
Re: Interlace modes with r600 KMS
Am 09.09.2010 17:03, schrieb Alex Deucher: Does disabling underscan fix interlaced? I just pulled the latest d-r-t and at least I can confirm that the problem is present without any of my tinkerings :-) I still need to check with underscan disabled. There is no cmdline option for this yet, is there? What's the quickest way to disable underscan, replace UNDERSCAN_AUTO with UNDERSCAN_OFF? Regards Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Interlace modes with r600 KMS
Am 08.09.2010 00:00, wrote Alex Deucher: > What card do you have? Can you dump the registers with both kms and > ums with an interlaced mode set and send them to me? Use avivotool I have a GA-MA78GM-UD2H mainboard with an onboard RS780 chipset. I sent the requested dumps in a PM. While typing this I realize that I don't use a pristine d-r-t. I did fiddle with the HDMI underscan settings a bit to make my 1280x720p mode fit better. That fiddling went so far that I broke the original ratio a little bit. Just to let you know. Thanks Marius
Re: Interlace modes with r600 KMS
Am 08.09.2010 00:00, wrote Alex Deucher: What card do you have? Can you dump the registers with both kms and ums with an interlaced mode set and send them to me? Use avivotool I have a GA-MA78GM-UD2H mainboard with an onboard RS780 chipset. I sent the requested dumps in a PM. While typing this I realize that I don't use a pristine d-r-t. I did fiddle with the HDMI underscan settings a bit to make my 1280x720p mode fit better. That fiddling went so far that I broke the original ratio a little bit. Just to let you know. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Interlace modes with r600 KMS
Am 07.09.2010 21:00, schrieb Alex Deucher: > Does this patch help? No change... > If not, does it work ok with ums (boot with radeon.modeset=0)? If so, > we'll need to compare the modesetting paths between ums and kms and > see what got broken with kms. Without KMS the interlaced modes are listed in xrandr right away, and they are working! Marius
Interlace modes with r600 KMS
Am 07.09.2010 17:53, schrieb Alex Deucher: > It did in the past, however, at the moment, I don't have a interlaced > capable monitor to test. Can you try again with xf86-video-ati from > git master? No change, at all, unfortunately. The interlace modes, while listed in Xorg.conf, are not visible in xrandr. Manually adding an interlaced mode with xrandr results in a broken screen display. Any other thoughts? Regards Marius
Interlace modes with r600 KMS
Am 07.09.2010 17:53, wrote Alex Deucher: > It did in the past, however, at the moment, I don't have a interlaced > capable monitor to test. Can you try again with xf86-video-ati from > git master? I'll try, thanks. Marius
Interlace modes with r600 KMS
Am 07.09.2010 16:52, wrote Alex Deucher: > 2010/9/7 Marius Gr?ger: >> Hi All, >> >> I'm not able to use interlace modes (r600 KMS from d-r-t, HDMI output, Xorg >> stack on xorg-edgers, Ubuntu lucid). All interlace modes which are defined >> in EDID seem to be pruned and don't appear in xrandr. Manually adding a mode >> using xrandr does work, and the TV set detects the mode, but the image shows >> horizontal lines. No crash though. >> >> Interlace modes did use to work fine in the past, but I don't know when they >> ceased to function. >> >> What is the status of interlace modes on this kind of setup? What more tests >> or logs would be helpful to analyze the problem? What are other people's >> experiences with this? > > This isn't a driver bug as far as I can tell. At some point the > Xserver started purging interlaced modes. See this bug: > https://bugs.freedesktop.org/show_bug.cgi?id=29591 Thanks for the pointer. I did look into the xserver sources a bit and while I'm far from understanding exactly what's going on, it seems like the server is relying on output->interlaceAllowed and output->doubleScanAllowed. Aren't these bools in the domain of the display driver (granted, this wouldn't be the radeon module but the xf86-video-ati driver)? Also, as I wrote, the purging seems to be half-done, since I am able to manually add an interlaced mode. But since that mode doesn't work properly - does the radeon module support interlaced modes? Is there a non-X way to verify this? Regards Marius
Interlace modes with r600 KMS
Hi All, I'm not able to use interlace modes (r600 KMS from d-r-t, HDMI output, Xorg stack on xorg-edgers, Ubuntu lucid). All interlace modes which are defined in EDID seem to be pruned and don't appear in xrandr. Manually adding a mode using xrandr does work, and the TV set detects the mode, but the image shows horizontal lines. No crash though. Interlace modes did use to work fine in the past, but I don't know when they ceased to function. What is the status of interlace modes on this kind of setup? What more tests or logs would be helpful to analyze the problem? What are other people's experiences with this? Thanks Marius
Interlace modes with r600 KMS
Hi All, I'm not able to use interlace modes (r600 KMS from d-r-t, HDMI output, Xorg stack on xorg-edgers, Ubuntu lucid). All interlace modes which are defined in EDID seem to be pruned and don't appear in xrandr. Manually adding a mode using xrandr does work, and the TV set detects the mode, but the image shows horizontal lines. No crash though. Interlace modes did use to work fine in the past, but I don't know when they ceased to function. What is the status of interlace modes on this kind of setup? What more tests or logs would be helpful to analyze the problem? What are other people's experiences with this? Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Interlace modes with r600 KMS
Am 07.09.2010 17:53, schrieb Alex Deucher: It did in the past, however, at the moment, I don't have a interlaced capable monitor to test. Can you try again with xf86-video-ati from git master? No change, at all, unfortunately. The interlace modes, while listed in Xorg.conf, are not visible in xrandr. Manually adding an interlaced mode with xrandr results in a broken screen display. Any other thoughts? Regards Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 09.08.2010 09:33, wrote Alex Deucher: > 2010/8/9 Marius Gr?ger: >> Am 08.08.2010 20:09, wrote Alex Deucher: >>> >>> 2010/8/8 Marius Gr?ger: Am 08.08.2010 18:22, wrote Alex Deucher: >> >> Also, I kind of was hoping that once I could use 1280x720 for both the >> console and the X screen, it would would allow me to switch between the >> two >> transparently. Instead, the TV takes notice of the switch and needs >> some >> extra syncing time. Is this expected behaviour? > > You mean switching underscan off and on or a VT switch? The hw has to > reprogram the mode when it changes the underscan. As for a VT switch, > it should just be changing the crtc base, but IIRC there was a bug > where X and the console used slightly different modes in some cases. VT switch. I use video=1280x720 at 50 on the command line and select the corresponding EDID resolution within X. Is this bug still pending or is my scenario supposed to work? >>> >>> You may be seeing this issue: >>> http://lists.x.org/archives/xorg-devel/2010-August/011743.html >> >> "In the absence of the user specifying an overriding monitor >> configuration, trust the KMS drivers to have correctly probed the output >> modes." >> >> Well, in my case I *am* specifying an overriding monitor configuration. Is >> there still a chance that video=1280x720 at 50 could be meaning s.th. >> different >> then the corresponding mode in X that I explicitly choose. > > Can you verify that the console and X are using the same modeline? > The mode selected by video=1280x720 at 50 likely has different timing > than the timing used by the mode in X. Is the VT switch smooth when > you don't specify the mode on the console or X (i.e., let the driver > decide on it's own)? Ah ok, "likely has different timing" - this is probably the issue here. I'll be investigating this. Is there a way to influence the timing used by video=1280x720 at 50 to match the one used in X? Or should I try finding out about the console timing and use that as an xorg.conf modeline? Regards Marius
[PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 08.08.2010 20:09, wrote Alex Deucher: > 2010/8/8 Marius Gr?ger: >> Am 08.08.2010 18:22, wrote Alex Deucher: Also, I kind of was hoping that once I could use 1280x720 for both the console and the X screen, it would would allow me to switch between the two transparently. Instead, the TV takes notice of the switch and needs some extra syncing time. Is this expected behaviour? >>> >>> You mean switching underscan off and on or a VT switch? The hw has to >>> reprogram the mode when it changes the underscan. As for a VT switch, >>> it should just be changing the crtc base, but IIRC there was a bug >>> where X and the console used slightly different modes in some cases. >> >> VT switch. I use video=1280x720 at 50 on the command line and select the >> corresponding EDID resolution within X. Is this bug still pending or is my >> scenario supposed to work? > > You may be seeing this issue: > http://lists.x.org/archives/xorg-devel/2010-August/011743.html "In the absence of the user specifying an overriding monitor configuration, trust the KMS drivers to have correctly probed the output modes." Well, in my case I *am* specifying an overriding monitor configuration. Is there still a chance that video=1280x720 at 50 could be meaning s.th. different then the corresponding mode in X that I explicitly choose. Regards Marius
[PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 08.08.2010 18:22, wrote Alex Deucher: >> Also, I kind of was hoping that once I could use 1280x720 for both the >> console and the X screen, it would would allow me to switch between the two >> transparently. Instead, the TV takes notice of the switch and needs some >> extra syncing time. Is this expected behaviour? > > You mean switching underscan off and on or a VT switch? The hw has to > reprogram the mode when it changes the underscan. As for a VT switch, > it should just be changing the crtc base, but IIRC there was a bug > where X and the console used slightly different modes in some cases. VT switch. I use video=1280x720 at 50 on the command line and select the corresponding EDID resolution within X. Is this bug still pending or is my scenario supposed to work? Regards Marius
[PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 04.08.2010 16:35, schrieb Alex Deucher: > 2010/8/4 Marius Gr?ger: >> Am 04.08.2010 01:59, schrieb Alex Deucher: >>> >>> This connector attribute allows you to enable or disable underscan >>> on a digital output to compensate for panels that automatically >>> overscan (e.g., many HDMI TVs). Valid values for the attribute are: >>> >>> off - forces underscan off >>> on - forces underscan on >>> auto - enables underscan if an HDMI TV is connected, off otherwise >>> >>> default value is auto. >> >> Terrific! Two questions: >> >> - inevitably, on my TV Set (SONY KDL 3000) this now doing too much >> underscan. In pixels: without your patch, I used a custom modeline to >> map 1280x720p to 1220x680p, so I'm 40 pixels down in each dimension. How to >> fix that? > > Adjust radeon_crtc->v_border and radeon_crtc->h_border in the patch to > whatever size you want. Thanks. It turns out that I need different values to fit the screen (probably due to native 1366/768 != 1280/720). This is of course at the cost of slightly changing the rendered ratio, but that's fine with me. Any plans to make those values tunables? Also, I kind of was hoping that once I could use 1280x720 for both the console and the X screen, it would would allow me to switch between the two transparently. Instead, the TV takes notice of the switch and needs some extra syncing time. Is this expected behaviour? Thanks Marius
Re: [PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 04.08.2010 16:35, schrieb Alex Deucher: 2010/8/4 Marius Grögermarius.groe...@googlemail.com: Am 04.08.2010 01:59, schrieb Alex Deucher: This connector attribute allows you to enable or disable underscan on a digital output to compensate for panels that automatically overscan (e.g., many HDMI TVs). Valid values for the attribute are: off - forces underscan off on - forces underscan on auto - enables underscan if an HDMI TV is connected, off otherwise default value is auto. Terrific! Two questions: - inevitably, on my TV Set (SONY KDL 3000) this now doing too much underscan. In pixels: without your patch, I used a custom modeline to map 1280x720p to 1220x680p, so I'm 40 pixels down in each dimension. How to fix that? Adjust radeon_crtc-v_border and radeon_crtc-h_border in the patch to whatever size you want. Thanks. It turns out that I need different values to fit the screen (probably due to native 1366/768 != 1280/720). This is of course at the cost of slightly changing the rendered ratio, but that's fine with me. Any plans to make those values tunables? Also, I kind of was hoping that once I could use 1280x720 for both the console and the X screen, it would would allow me to switch between the two transparently. Instead, the TV takes notice of the switch and needs some extra syncing time. Is this expected behaviour? Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 08.08.2010 18:22, wrote Alex Deucher: Also, I kind of was hoping that once I could use 1280x720 for both the console and the X screen, it would would allow me to switch between the two transparently. Instead, the TV takes notice of the switch and needs some extra syncing time. Is this expected behaviour? You mean switching underscan off and on or a VT switch? The hw has to reprogram the mode when it changes the underscan. As for a VT switch, it should just be changing the crtc base, but IIRC there was a bug where X and the console used slightly different modes in some cases. VT switch. I use video=1280x...@50 on the command line and select the corresponding EDID resolution within X. Is this bug still pending or is my scenario supposed to work? Regards Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 04.08.2010 01:59, schrieb Alex Deucher: > This connector attribute allows you to enable or disable underscan > on a digital output to compensate for panels that automatically > overscan (e.g., many HDMI TVs). Valid values for the attribute are: > > off - forces underscan off > on - forces underscan on > auto - enables underscan if an HDMI TV is connected, off otherwise > > default value is auto. Terrific! Two questions: - inevitably, on my TV Set (SONY KDL 3000) this now doing too much underscan. In pixels: without your patch, I used a custom modeline to map 1280x720p to 1220x680p, so I'm 40 pixels down in each dimension. How to fix that? - more of a general drm question I guess: in what way are the connector attributes available on the command line? I couldn't find a complete kernel command line or modprobe invocation. Thanks Marius
Re: [PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
Am 04.08.2010 01:59, schrieb Alex Deucher: This connector attribute allows you to enable or disable underscan on a digital output to compensate for panels that automatically overscan (e.g., many HDMI TVs). Valid values for the attribute are: off - forces underscan off on - forces underscan on auto - enables underscan if an HDMI TV is connected, off otherwise default value is auto. Terrific! Two questions: - inevitably, on my TV Set (SONY KDL 3000) this now doing too much underscan. In pixels: without your patch, I used a custom modeline to map 1280x720p to 1220x680p, so I'm 40 pixels down in each dimension. How to fix that? - more of a general drm question I guess: in what way are the connector attributes available on the command line? I couldn't find a complete kernel command line or modprobe invocation. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
Am 07.06.2010 00:15, wrote Dave Airlie: On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger marius.groe...@googlemail.com wrote: Am 06.06.2010 18:47, schrieb James Simmons: Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used. I have found the cause for the glitch and just filed http://bugs.freedesktop.org/show_bug.cgi?id=28411. Okay I can see the problem, now I have to think of a good solution, I probably need to break down the locking a bit further which is a bit messy. Is there any news on this issue? I didn't notice any commits to d-r-t or d-n WRT this, but then again those repos aren't updated very frequently anyway (how come?) Thanks T Regards, Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Suspend lockup: How to bisect d-r-t specific commits?
Am 20.07.2010 12:14, schrieb Rafa? Mi?ecki: > I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added > 2.6.35-rc5 from package. In both cases suspending and resuming works > fine. > > Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and > resuming works fine. > > When trying d-r-t with the same config my machine locks up on > suspending, just before machine is expected to turn off. > > How can I use "git bisect" command to bisect d-r-t specific commits? Fwiw, for me (HD3200, RS780) current d-r-t resume from suspend to ram does not work. Last thing it shows is the text console with some random colored pixels, but not the X display where it was suspended from. It appeared liked the kernel was still running, but X was completely crashed and stuck. I haven't had the time yet to further debug this. Regards Marius
Glitch in newer drm-next/drm-radeon-testing
Am 06.06.2010 18:47, schrieb James Simmons: > >>> Apologies for such an unspecific description, and for what almost seems >>> like a support request for MythTV. I wouldn't post here if I were not >>> 100% sure it must be related with the recent drm changes. >> >> Note that the DRM APIs are intended for use by userspace components of >> graphics drivers / API libraries, not applications directly. MythTV >> shouldn't use the DRM directly for synchronization but rather use GLX >> synchronization APIs. > > Tho not the case for MythTV on a embedded device requiring apps to use GLX > wuld be to heavy. I would agree libdrm should be used. I have found the cause for the glitch and just filed http://bugs.freedesktop.org/show_bug.cgi?id=28411. Regards Marius
Glitch in newer drm-next/drm-radeon-testing
Am 04.06.2010 17:17, schrieb Alex Deucher: > 2010/6/4 Marius Gr?ger: >> Alex Deucher schrieb: >>> 2010/6/4 Marius Gr?ger: Hi All, Michel D?nzer schrieb: > On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote: >> Hello All, >> >> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and >> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary >> application is mythtv which uses DRM syncing for the frame >> syncronisation. Now, with the exact same userland software I noticed the >> introduction of sync gliches in the May-timeframe. The >> drm-radeon-testing on May 9 was still ok, but both drm-next and >> drm-radeon-testing at the end of May showed that glitch: every couple of >> seconds there's a very visual hickup, especially in scroll texts. >> >> Apologies for such an unspecific description, and for what almost seems >> like a support request for MythTV. I wouldn't post here if I were not >> 100% sure it must be related with the recent drm changes. > Note that the DRM APIs are intended for use by userspace components of > graphics drivers / API libraries, not applications directly. MythTV > shouldn't use the DRM directly for synchronization but rather use GLX > synchronization APIs. [...] > Any chance you can bisect the problematic commit? I did a second attempt at bisecting and now I'm confident it is this commit which broke my real-time performance in mythtv: commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie Date: Fri May 7 06:42:51 2010 + drm/fbdev: rework output polling to be back in the core. (v4) Having found the commit is the good news. The bad news is that this commit is rather large, so again I'd be depended on the experts around here to isolate what's going on. Dave, would you mind giving a hand as well as the author of this commit? Thanks Marius
Re: Glitch in newer drm-next/drm-radeon-testing
Am 04.06.2010 17:17, schrieb Alex Deucher: 2010/6/4 Marius Grögermarius.groe...@googlemail.com: Alex Deucher schrieb: 2010/6/4 Marius Grögermarius.groe...@googlemail.com: Hi All, Michel Dänzer schrieb: On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote: Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. [...] Any chance you can bisect the problematic commit? I did a second attempt at bisecting and now I'm confident it is this commit which broke my real-time performance in mythtv: commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie airl...@redhat.com Date: Fri May 7 06:42:51 2010 + drm/fbdev: rework output polling to be back in the core. (v4) Having found the commit is the good news. The bad news is that this commit is rather large, so again I'd be depended on the experts around here to isolate what's going on. Dave, would you mind giving a hand as well as the author of this commit? Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Glitch in newer drm-next/drm-radeon-testing
Am Fri, 4 Jun 2010 11:17:12 -0400 schrieb Alex Deucher : > 2010/6/4 Marius Gr?ger : > > Alex Deucher schrieb: > >> 2010/6/4 Marius Gr?ger : > >>> Hi All, > >>> > >>> Michel D?nzer schrieb: > On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote: > > Hello All, > > > > I'm trying the top-of-trunk drm-2.6 trees (both drm-next and > > drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The > > primary application is mythtv which uses DRM syncing for the > > frame syncronisation. Now, with the exact same userland > > software I noticed the introduction of sync gliches in the > > May-timeframe. The drm-radeon-testing on May 9 was still ok, > > but both drm-next and drm-radeon-testing at the end of May > > showed that glitch: every couple of seconds there's a very > > visual hickup, especially in scroll texts. > > > > Apologies for such an unspecific description, and for what > > almost seems like a support request for MythTV. I wouldn't post > > here if I were not 100% sure it must be related with the recent > > drm changes. > Note that the DRM APIs are intended for use by userspace > components of graphics drivers / API libraries, not applications > directly. MythTV shouldn't use the DRM directly for > synchronization but rather use GLX synchronization APIs. > >>> What about that new dri2 vsync stuff which was mentioned related > >>> to [Bug 28383]? Could the changes done for that in any way alter > >>> the timing? BTW I measured the glitches I'm experiencing and the > >>> appear to be to happen in intervals of 10 seconds. Again, all I'm > >>> changing is the kernel, and even the kernel config is the same. > >>> I'd be most grateful for any clues/hints/tips I could follow to > >>> resolve this regression. > >>> > If you have dynamic PM enabled, does disabling that help? > >>> I checked again and there's method=profile and profile=default. > >>> Afaict this is not using dynpm, right? > >>> > >> > >> Correct. > > > > Ok so with dynpm more or less ruled out, what could have such a > > visible impact on the latencies? For instance, are we now more > > dependent (or less) on some kind of interrupt or deferred > > processing than 6 weeks ago? > > > > Btw, I have HDMI audio pretty much ruled out as well. > > Any chance you can bisect the problematic commit? As I said, I already tried bisecting but failed. Perhaps I can try again and replay at least part of the log... But since we're talking about more than 120 commits I kinda was hoping to get some clues here first. Even with a tailored .config building/rebooting/testing takes ages. Well I suppose I needn't tell *you* guys... ;-) Thanks Marius
Glitch in newer drm-next/drm-radeon-testing
Alex Deucher schrieb: > 2010/6/4 Marius Gr?ger : >> Hi All, >> >> Michel D?nzer schrieb: >>> On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote: Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. >>> Note that the DRM APIs are intended for use by userspace components of >>> graphics drivers / API libraries, not applications directly. MythTV >>> shouldn't use the DRM directly for synchronization but rather use GLX >>> synchronization APIs. >> What about that new dri2 vsync stuff which was mentioned related to [Bug >> 28383]? Could the changes done for that in any way alter the timing? BTW >> I measured the glitches I'm experiencing and the appear to be to happen >> in intervals of 10 seconds. Again, all I'm changing is the kernel, and >> even the kernel config is the same. I'd be most grateful for any >> clues/hints/tips I could follow to resolve this regression. >> >>> If you have dynamic PM enabled, does disabling that help? >> I checked again and there's method=profile and profile=default. Afaict >> this is not using dynpm, right? >> > > Correct. Ok so with dynpm more or less ruled out, what could have such a visible impact on the latencies? For instance, are we now more dependent (or less) on some kind of interrupt or deferred processing than 6 weeks ago? Btw, I have HDMI audio pretty much ruled out as well. Thanks Marius
Glitch in newer drm-next/drm-radeon-testing
Hi All, Michel D?nzer schrieb: > On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote: >> Hello All, >> >> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and >> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary >> application is mythtv which uses DRM syncing for the frame >> syncronisation. Now, with the exact same userland software I noticed the >> introduction of sync gliches in the May-timeframe. The >> drm-radeon-testing on May 9 was still ok, but both drm-next and >> drm-radeon-testing at the end of May showed that glitch: every couple of >> seconds there's a very visual hickup, especially in scroll texts. >> >> Apologies for such an unspecific description, and for what almost seems >> like a support request for MythTV. I wouldn't post here if I were not >> 100% sure it must be related with the recent drm changes. > > Note that the DRM APIs are intended for use by userspace components of > graphics drivers / API libraries, not applications directly. MythTV > shouldn't use the DRM directly for synchronization but rather use GLX > synchronization APIs. What about that new dri2 vsync stuff which was mentioned related to [Bug 28383]? Could the changes done for that in any way alter the timing? BTW I measured the glitches I'm experiencing and the appear to be to happen in intervals of 10 seconds. Again, all I'm changing is the kernel, and even the kernel config is the same. I'd be most grateful for any clues/hints/tips I could follow to resolve this regression. > If you have dynamic PM enabled, does disabling that help? I checked again and there's method=profile and profile=default. Afaict this is not using dynpm, right? Marius
Re: Glitch in newer drm-next/drm-radeon-testing
Hi All, Michel Dänzer schrieb: On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote: Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. What about that new dri2 vsync stuff which was mentioned related to [Bug 28383]? Could the changes done for that in any way alter the timing? BTW I measured the glitches I'm experiencing and the appear to be to happen in intervals of 10 seconds. Again, all I'm changing is the kernel, and even the kernel config is the same. I'd be most grateful for any clues/hints/tips I could follow to resolve this regression. If you have dynamic PM enabled, does disabling that help? I checked again and there's method=profile and profile=default. Afaict this is not using dynpm, right? Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
Alex Deucher schrieb: 2010/6/4 Marius Gröger marius.groe...@googlemail.com: Hi All, Michel Dänzer schrieb: On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote: Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. What about that new dri2 vsync stuff which was mentioned related to [Bug 28383]? Could the changes done for that in any way alter the timing? BTW I measured the glitches I'm experiencing and the appear to be to happen in intervals of 10 seconds. Again, all I'm changing is the kernel, and even the kernel config is the same. I'd be most grateful for any clues/hints/tips I could follow to resolve this regression. If you have dynamic PM enabled, does disabling that help? I checked again and there's method=profile and profile=default. Afaict this is not using dynpm, right? Correct. Ok so with dynpm more or less ruled out, what could have such a visible impact on the latencies? For instance, are we now more dependent (or less) on some kind of interrupt or deferred processing than 6 weeks ago? Btw, I have HDMI audio pretty much ruled out as well. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Glitch in newer drm-next/drm-radeon-testing
Hi Michel, Michel D?nzer schrieb: > Note that the DRM APIs are intended for use by userspace components of > graphics drivers / API libraries, not applications directly. MythTV > shouldn't use the DRM directly for synchronization but rather use GLX > synchronization APIs. Hm, ok... AFAIK MythTV tries several sync mechanisms with DRM being preferred. I tried with OpenGL syncing but the issue remains. > If you have dynamic PM enabled, does disabling that help? No I don't have that enabled. Any other ideas? Thanks Marius
Glitch in newer drm-next/drm-radeon-testing
Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. What I've tried so far: * I tried bisecting, but I failed to spot the offending commits somehow. My last hope is this list of experts - for me the git logs look sane, but you guy surely have more insight. * I tried turning on drm debug=1, but did not see anything suspicious, especially with relation to the r600 irq handling changes. * Currently I'm in the process of setting up systemtap to profile the scheduling, but I'm still on the learning curve :) I'd be most grateful for any tips and things to try to isolate this issue. Thanks Marius
Glitch in newer drm-next/drm-radeon-testing
Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. What I've tried so far: * I tried bisecting, but I failed to spot the offending commits somehow. My last hope is this list of experts - for me the git logs look sane, but you guy surely have more insight. * I tried turning on drm debug=1, but did not see anything suspicious, especially with relation to the r600 irq handling changes. * Currently I'm in the process of setting up systemtap to profile the scheduling, but I'm still on the learning curve :) I'd be most grateful for any tips and things to try to isolate this issue. Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
Hi Michel, Michel Dänzer schrieb: Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. Hm, ok... AFAIK MythTV tries several sync mechanisms with DRM being preferred. I tried with OpenGL syncing but the issue remains. If you have dynamic PM enabled, does disabling that help? No I don't have that enabled. Any other ideas? Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
