Re: [ANNOUNCE] xf86-video-intel 2.5.99.2
Hi, I tried to enable UXA. At least glxgears shows some gears now. However, I'm not sure if it is hardware accellerated. 1. neverball in fullscreen is damn slow (looks like software rendering). After exit, the screen is empty. Luckily, I can blindly open the Xfce menu and exit the session, a server restart restores the graphics 2. googleearth is also damn slow (software rendering?) Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 945GM(E) screen rotation and slow GL.
Keith Packard wrote: >> Do you think the 945 chipset is just too slow to rotate a 1920x1200 >> screen? > > One thing that may improve performance a bit is when we get tiling > support for the displayed buffer. That work requires some additional > kernel infrastructure to manage the 'fence' registers which are > responsible for linearizing tiled regions for software rendering code. > > You might try 16bpp instead of 32bpp; it won't look as good, but it > should go faster. Tried that: 85 fps in normal mode, 27 fps for left-rotation. Would a board with a 965GM chipset fare much better, you think? I haven't seen many small form-factor embedded boards with that chipset yet, unfortunately. Cheers, Rob ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.5.99.2
Hi, in Xorg.0.log, I also found these lines: (**) intel(0): Framebuffer compression enabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (EE) intel(0): Failed to set tiling on front buffer: rejected by kernel (EE) intel(0): Failed to set tiling on back buffer: rejected by kernel (EE) intel(0): Failed to set tiling on depth buffer: rejected by kernel I wonder why the first two lines are prefixed with (**). I have no options in my xorg.conf to specify any framebuffer compression or tiling behaviour. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: [ANNOUNCE] xf86-video-intel 2.5.99.2
Johannes Engel wrote on Tuesday, January 13, 2009 6:23 PM: > Jin, Gordon wrote: >> Please let me know if any questions. > What's about the combination XvMC + UXA on 915/945? That seems not to > work, can we expect that back? Right, this doesn't work so zhenyu disabled it in this release. I'm not sure when it can be worked out. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 945GM(E) screen rotation and slow GL.
On Wed, 2009-01-14 at 13:18 +0800, Rob Kramer wrote: > Cool, thanks. That's a lot better at 18 fps, but still a lot worse than > normal landscape operation. Is that expected? I thought with modern GL > setups, rotation basically came for free -- but I'm a GL newbie :) The rotation is done by drawing to an upright frame buffer and then copying that to the rotated frame buffer for presentation. That's a lot of pixels to copy around each frame. > Do you think the 945 chipset is just too slow to rotate a 1920x1200 > screen? You're fairly seriously memory bandwidth limited with that chipset, and at that resolution. One thing that may improve performance a bit is when we get tiling support for the displayed buffer. That work requires some additional kernel infrastructure to manage the 'fence' registers which are responsible for linearizing tiled regions for software rendering code. You might try 16bpp instead of 32bpp; it won't look as good, but it should go faster. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 945GM(E) screen rotation and slow GL.
Keith Packard wrote: > On Wed, 2009-01-14 at 09:51 +0800, Rob Kramer wrote: > >> When testing screen rotation to portrait mode, the glxgears framerate >> drops from 51 fps (not too great to start with) to 1 fps. > > Thanks! We lost our rotation acceleration when we switched to dri_bo's > for pixmaps. Cool, thanks. That's a lot better at 18 fps, but still a lot worse than normal landscape operation. Is that expected? I thought with modern GL setups, rotation basically came for free -- but I'm a GL newbie :) Do you think the 945 chipset is just too slow to rotate a 1920x1200 screen? Cheers! Rob ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 945GM(E) screen rotation and slow GL.
On Wed, 2009-01-14 at 09:51 +0800, Rob Kramer wrote:
> When testing screen rotation to portrait mode, the glxgears framerate drops
> from 51 fps (not too great to start with) to 1 fps.
Thanks! We lost our rotation acceleration when we switched to dri_bo's
for pixmaps.
Try this patch:
diff --git a/src/i830_display.c b/src/i830_display.c
index 50fbc4d..4fba1fb 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -1601,6 +1601,7 @@ static PixmapPtr
i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, int width, int height)
{
ScrnInfoPtr pScrn = crtc->scrn;
+I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
I830Ptr pI830 = I830PTR(pScrn);
int rotate_pitch;
PixmapPtr rotate_pixmap;
@@ -1621,6 +1622,8 @@ i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, int
width, int height)
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Couldn't allocate shadow pixmap for rotated CRTC\n");
}
+if (intel_crtc->rotate_mem && intel_crtc->rotate_mem->bo)
+ i830_set_pixmap_bo(rotate_pixmap, intel_crtc->rotate_mem->bo);
return rotate_pixmap;
}
--
keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: drm_crtc.c WARNING: drm_mode_object_get() called w/o mode_config lock
On Wed, Jan 14, 2009 at 10:13:03AM +0800, Wu Fengguang wrote: > Hi, > > I got the following mutex-not-locked warning in linux 2.6.29-rc1. > It appears in a HP 6910p notebook and another G45 desktop. > > [ 357.150892] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > [ 357.157653] pci :00:02.0: setting latency timer to 64 > [ 357.169915] pci :00:02.0: irq 26 for MSI/MSI-X > [ 357.497053] [ cut here ] > [ 357.501715] WARNING: at drivers/gpu/drm/drm_crtc.c:213 > drm_mode_object_get+0xb7/0xc0() > [ 357.509662] Hardware name: > [ 357.513186] drm_mode_object_get called w/o mode_config lock > [ 357.518777] Modules linked in: i915(+) fb cfbcopyarea cfbimgblt > cfbfillrect snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel > snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd > soundcore snd_page_alloc > [ 357.539346] Pid: 3364, comm: modprobe Not tainted 2.6.29-rc1 #45 > [ 357.545377] Call Trace: > [ 357.547831] [] warn_slowpath+0xd0/0x130 > [ 357.553349] [] ? trace_hardirqs_on_caller+0x17a/0x1d0 > [ 357.560073] [] ? native_sched_clock+0x20/0x80 > [ 357.566118] [] ? sched_clock+0x9/0x10 > [ 357.571446] [] ? _spin_unlock_irqrestore+0x3f/0x70 > [ 357.577906] [] ? trace_hardirqs_on_caller+0x17a/0x1d0 > [ 357.584625] [] ? try_to_del_timer_sync+0x5a/0x70 > [ 357.590914] [] ? > drm_mode_connector_update_edid_property+0x63/0x180 > [ 357.598854] [] ? > cache_alloc_debugcheck_after+0x159/0x250 > [ 357.605919] [] drm_mode_object_get+0xb7/0xc0 > [ 357.611854] [] > drm_mode_connector_update_edid_property+0x95/0x180 > [ 357.619647] [] intel_ddc_get_modes+0x3d/0x70 [i915] > [ 357.626194] [] intel_hdmi_get_modes+0x9/0x10 [i915] > [ 357.632730] [] > drm_helper_probe_single_connector_modes+0xa6/0x2e0 > [ 357.640493] [] > drm_helper_probe_connector_modes+0x3e/0x70 > [ 357.647571] [] drm_helper_plugged_event+0x3a/0x330 > [ 357.654032] [] drm_helper_initial_config+0x9/0x10 > [ 357.660407] [] i915_driver_load+0x8eb/0xa30 [i915] > [ 357.666868] [] drm_get_dev+0x2fc/0x490 > [ 357.672308] [] drm_init+0x9e/0xf0 > [ 357.677301] [] ? i915_init+0x0/0x4e [i915] > [ 357.683070] [] i915_init+0x4c/0x4e [i915] > [ 357.688750] [] _stext+0x3a/0x1d0 > [ 357.693653] [] ? mark_held_locks+0x56/0xa0 > [ 357.699416] [] ? mutex_lock_nested+0x276/0x370 > [ 357.705535] [] ? mark_held_locks+0x56/0xa0 > [ 357.711292] [] ? native_sched_clock+0x20/0x80 > [ 357.717320] [] ? sched_clock+0x9/0x10 > [ 357.722652] [] ? _spin_unlock_irqrestore+0x3f/0x70 > [ 357.729114] [] ? _spin_unlock_irqrestore+0x3f/0x70 > [ 357.735570] [] ? trace_hardirqs_on_caller+0x17a/0x1d0 > [ 357.742312] [] ? trace_hardirqs_on+0xd/0x10 > [ 357.748166] [] ? __up_read+0x84/0xb0 > [ 357.753416] [] ? up_read+0x26/0x30 > [ 357.758479] [] ? > __blocking_notifier_call_chain+0x69/0x90 > [ 357.765540] [] sys_init_module+0xaf/0x200 > [ 357.771220] [] system_call_fastpath+0x16/0x1b > [ 357.777249] ---[ end trace 3c284735efa217aa ]--- It caused the events/0 thread to stuck in i915_gem_retire_work_handler() and other threads to stuck in flush_work()/flush_cpu_work(): % ps -o pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm ax | grep D PID TID CLS RTPRIO NI PRI PSR %CPU STAT WCHAN COMMAND 9 9 TS - -5 24 0 0.1 D< i915_gem_retir events/0 267 267 TS - -5 24 0 0.0 D< flush_work kondemand/0 2872 2872 TS - 0 19 0 0.0 Ds flush_cpu_work getty 2875 2875 TS - 0 19 0 0.0 Ds flush_cpu_work getty 2876 2876 TS - 0 19 0 0.0 Ds flush_cpu_work getty 2879 2879 TS - 0 19 0 0.0 Ds flush_cpu_work getty 2882 2882 TS - 0 19 1 0.0 Ds flush_cpu_work getty 2883 2883 TS - 0 19 0 0.0 Ds flush_cpu_work getty 3295 3295 TS - 0 19 1 0.0 Dflush_work killall5 [ 369.005494] events/0 D 4552 9 2 [ 369.005494] 88001b515d70 0046 88001b515ce0 8800031c9200 [ 369.005494] 818d6200 88001b510280 815f14a0 88001b5105c8 [ 369.005494] 1b515d20 8899 8800031c9218 0002 [ 369.005494] Call Trace: [ 369.005494] [] ? mutex_lock_nested+0x215/0x370 [ 369.005494] [] mutex_lock_nested+0x16f/0x370 [ 369.005494] [] ? i915_gem_retire_work_handler+0x3a/0x90 [i915] [ 369.005494] [] ? i915_gem_retire_work_handler+0x3a/0x90 [i915] [ 369.005494] [] i915_gem_retire_work_handler+0x3a/0x90 [i915] [ 369.005494] [] ? i915_gem_retire_work_handler+0x0/0x90 [i915] [ 369.005494] [] run_workqueue+0x105/0x240 [ 369.005494] [] ? run_workqueue+0xb3/0x240 [ 369.005494] [] worker_thread+0xaf/0x130 [ 369.005494] [] ? autoremove_wake_function+0x0/0x40 [ 369.005494] [] ? worker_thread+0x0/0x130 [ 369.005494] [] kthread+0x49/0x90 [ 369.005494] [] child_rip+0xa/0x20 [ 369.005494] [] ? restore_a
drm_crtc.c WARNING: drm_mode_object_get() called w/o mode_config lock
Hi, I got the following mutex-not-locked warning in linux 2.6.29-rc1. It appears in a HP 6910p notebook and another G45 desktop. [ 357.150892] pci :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 357.157653] pci :00:02.0: setting latency timer to 64 [ 357.169915] pci :00:02.0: irq 26 for MSI/MSI-X [ 357.497053] [ cut here ] [ 357.501715] WARNING: at drivers/gpu/drm/drm_crtc.c:213 drm_mode_object_get+0xb7/0xc0() [ 357.509662] Hardware name: [ 357.513186] drm_mode_object_get called w/o mode_config lock [ 357.518777] Modules linked in: i915(+) fb cfbcopyarea cfbimgblt cfbfillrect snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc [ 357.539346] Pid: 3364, comm: modprobe Not tainted 2.6.29-rc1 #45 [ 357.545377] Call Trace: [ 357.547831] [] warn_slowpath+0xd0/0x130 [ 357.553349] [] ? trace_hardirqs_on_caller+0x17a/0x1d0 [ 357.560073] [] ? native_sched_clock+0x20/0x80 [ 357.566118] [] ? sched_clock+0x9/0x10 [ 357.571446] [] ? _spin_unlock_irqrestore+0x3f/0x70 [ 357.577906] [] ? trace_hardirqs_on_caller+0x17a/0x1d0 [ 357.584625] [] ? try_to_del_timer_sync+0x5a/0x70 [ 357.590914] [] ? drm_mode_connector_update_edid_property+0x63/0x180 [ 357.598854] [] ? cache_alloc_debugcheck_after+0x159/0x250 [ 357.605919] [] drm_mode_object_get+0xb7/0xc0 [ 357.611854] [] drm_mode_connector_update_edid_property+0x95/0x180 [ 357.619647] [] intel_ddc_get_modes+0x3d/0x70 [i915] [ 357.626194] [] intel_hdmi_get_modes+0x9/0x10 [i915] [ 357.632730] [] drm_helper_probe_single_connector_modes+0xa6/0x2e0 [ 357.640493] [] drm_helper_probe_connector_modes+0x3e/0x70 [ 357.647571] [] drm_helper_plugged_event+0x3a/0x330 [ 357.654032] [] drm_helper_initial_config+0x9/0x10 [ 357.660407] [] i915_driver_load+0x8eb/0xa30 [i915] [ 357.666868] [] drm_get_dev+0x2fc/0x490 [ 357.672308] [] drm_init+0x9e/0xf0 [ 357.677301] [] ? i915_init+0x0/0x4e [i915] [ 357.683070] [] i915_init+0x4c/0x4e [i915] [ 357.688750] [] _stext+0x3a/0x1d0 [ 357.693653] [] ? mark_held_locks+0x56/0xa0 [ 357.699416] [] ? mutex_lock_nested+0x276/0x370 [ 357.705535] [] ? mark_held_locks+0x56/0xa0 [ 357.711292] [] ? native_sched_clock+0x20/0x80 [ 357.717320] [] ? sched_clock+0x9/0x10 [ 357.722652] [] ? _spin_unlock_irqrestore+0x3f/0x70 [ 357.729114] [] ? _spin_unlock_irqrestore+0x3f/0x70 [ 357.735570] [] ? trace_hardirqs_on_caller+0x17a/0x1d0 [ 357.742312] [] ? trace_hardirqs_on+0xd/0x10 [ 357.748166] [] ? __up_read+0x84/0xb0 [ 357.753416] [] ? up_read+0x26/0x30 [ 357.758479] [] ? __blocking_notifier_call_chain+0x69/0x90 [ 357.765540] [] sys_init_module+0xaf/0x200 [ 357.771220] [] system_call_fastpath+0x16/0x1b [ 357.777249] ---[ end trace 3c284735efa217aa ]--- Thanks, Fengguang ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft XI 2 protocol specification
On Tue, Jan 13, 2009 at 08:44:04AM -0800, Keith Packard wrote: > On Tue, 2009-01-13 at 22:37 +1000, Peter Hutterer wrote: > > > The idea here was to be able to filter easily. I expect that many clients > > won't care much about reattachment, but they would care about new MDs. > > Having this information may prove useful. As for the deviceids - same idea. > > I guess this kinda depends on how we expect to implement things on the > client side. If we want to mirror the server device hierarchy in the > client library, it might be easier to just take the 'something changed' > event and reconstruct the whole client state than attempt to patch > things with incremental data. Dunno. I think most clients will care about the existence of MDs, but not as much about the actual hierarchy. That's my guess anyway, but tacking the data onto the event isn't hard from a coding perspective if we decide to do so. > > > Send these in floating point so we capture sub-pixel positions > > > trivially? > > > > ok. > > Or perhaps fixed point? That eliminates problems with different > precision in different parts of the screen. 16.16 would be the best choice since we're limited to 16 bits anway? > > > > Uh. What about absolute devices? Can those send XRelativeMotionEvents? > > > If so, this seems more like an XIDeviceRawEvent. > > > (same comments about last_* apply here) > > > > Good point. I will revise. > > Oh, are these INT32 here (for relative devices)? And, if so, do we use > INT32 in the non-raw event for consistency? for all events, screen coordinates are 16 (or 16.16 fixed point), all device coordinates are in a INT32 device coordinate system. We could opt for floats here too, but since scaling is required for device coordinates anyway, integers should suffice. > > Current deviceids are CARD8, so CARD32 would still require a > > reimplementation. > > Now, at least for XI2 this may not be a problem as we could decide the upper > > 24 bit as "reserved for future use" and continue to only use 8 bits in > > requests and replies - until those are reimplemented at a later point in > > time. > > I guess I don't see any huge 're-implementation' here -- you're just > widening a data type. It may cause a flag-day for input devices, but > we've been there before. widening a datatype from 8 to 32 still requires all protocol requests and replies to be widened, and therefore "reimplemented". Or am I missing something here? > > Another thing discussed briefly was the use of a separate format internal to > > the server, i.e. the XI events are assembled at delivery time, not carried > > through the server. This is an implementation detail though and shouldn't be > > too hard to support. > > Hmm. With the generic event stuff fixing the list-of-events disaster, is > there some other format you'd prefer? Adding a gratuitous data type > doesn't seem like a winning plan here. There's a bit of information that could be tacked on to the events that is quite important during event processing. Example is the SD change that causes the DeviceChangedEvent. This just needs to be a flag but because we're processing the on-wire event internally we don't have any room for it. So we need special-casing for the DCE all over the place. If we have an event struct that contains the data we'll need during event processing we can - pass additional data along throughout the process as we need it (daniel gave the example of latched/locked modifier information, and it'd be handy for frozen event processing too) - change processing without having to worry about the wire format - further clean up processing, as we don't have to typecast to the right events all over the place. The downside is that this would affect all extensions and is even more typing than the current proposal. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
945GM(E) screen rotation and slow GL.
Hi, I have an embedded board with 945GM chipset (1.8GHz Celeron M) connected via DVI to a 1920x1200 screen. I'm trying to benchmark GL performance a bit with glxgears, which should be good enough to give a rough estimate of the device's capabilities. (Is there a better generic GL benchmark tool?) When testing screen rotation to portrait mode, the glxgears framerate drops from 51 fps (not too great to start with) to 1 fps. I remember in the past there were always dire performance warnings regarding XAA and rotation; impact of shadow FBs and all that. Is that still a valid concern for a modern setup, i.e. is GL expected to be sluggish/unusable in rotated mode? Should I not use the 'rotate' feature at all, but rotate GL geometries/textures myself, in my application? (that would be painful, I guess). Using kernel 2.6.28.3. Xorg, drm, mesa are from Fedora rawhide. The intel driver is git HEAD. For the driver, it doesn't seem to make a difference whether I specify UXA or not. Cheers, Rob ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel/G45/1080 tearing
I just tried with the drm-intel-2.6.28 branch e1a6fcee467556a7e955fe1f7ccc134dd2f974e7 (2.6.28 + 6 patches) from the intellinuxgraphics site and the tearing is the same. the only other thing that I can try would be the mesa intel-2008-q4 branch. Would this be any different from the mesa master branch? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXi: commit 9911b7846ca2cedf08a963c84efe7907438975c1 breaks build
On Tue, Jan 13, 2009 at 2:30 PM, Johannes Engel wrote: > Hi Dan, > > could you please recheck your latest commit > 9911b7846ca2cedf08a963c84efe7907438975c1? Obviously being too smart > does not help in this case... ;) > > make[1]: Entering directory > `/home/engel/software/Xorg/lib/libXi/man' > > make[1]: *** No rule to create target > »XListDeviceProperties.3«, > used by »all-am«. Finish. > make[1]: Leaving directory > `/home/engel/software/Xorg/lib/libXi/man' > > make: *** [all-recursive] Error 1 Two questions: 1. Do you have xmlto? Is it detected by configure? 2. Are you using parallel make jobs? -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
libXi: commit 9911b7846ca2cedf08a963c84efe7907438975c1 breaks build
Hi Dan, could you please recheck your latest commit 9911b7846ca2cedf08a963c84efe7907438975c1? Obviously being too smart does not help in this case... ;) make[1]: Entering directory `/home/engel/software/Xorg/lib/libXi/man' make[1]: *** No rule to create target »XListDeviceProperties.3«, used by »all-am«. Finish. make[1]: Leaving directory `/home/engel/software/Xorg/lib/libXi/man' make: *** [all-recursive] Error 1 Cheers, Johannes ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel GLSL /w sdlmame (Was: Re: dga does't work correctly)
Steven Newbury wrote: > On Saturday 10 January 2009 04:33:36 tom fogal wrote: >> Steven Newbury writes: >> [snip] >> >>> (including using GLSL shaders for overlay effects, though sadly the >>> shader fails to compile with the intel driver for some reason [1]) >> [snip] >> >>> [1] >>> src/osd/sdl/gl_shader_tool.c:375: GL Error: object 0x3 compilation failed >>> src/osd/sdl/gl_shader_tool.c:375 glInfoLog: Error: >>> Error: failed to preprocess the source. >>> >>> failed to process shader: < >>> #pragma optimize (on) >>> #pragma debug (off) >> Try removing the pragma; doesn't look like it's supported yet in Mesa. >> >> t...@tomasu dev grep -i pragma mesa/src/mesa/shader/slang/*.c >> mesa/src/mesa/shader/slang/slang_preprocess.c:#define TOKEN_PRAGMA8 >> >> vs. `if', which seems to have an implementation: >> >> t...@tomasu dev grep -i token_if mesa/src/mesa/shader/slang/*.c >> mesa/src/mesa/shader/slang/slang_preprocess.c:#define TOKEN_IF3 >> mesa/src/mesa/shader/slang/slang_preprocess.c: case TOKEN_IF: >> >> Just a guess. > That got it running, although there is a serious problem with the > colour-space > conversion shader. Vector games seem to be fine though, with working overlay. I've fixed the #pragma directive in Mesa for the 7.3 release. If there's other bugs please file a bug report. -Brian ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.5.99.2
On Tue, Jan 13, 2009 at 17:24:10 +0800, Jin, Gordon wrote: [...] > Please let me know if any questions. Thanks for the information. However, still no luck. xorg-intel: 2.5.99.2 kernel: e1a6fcee467556a7e955fe1f7ccc134dd2f974e7 from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel, branch drm-intel-2.6.28 mesa: b9921a9fb2bc937194eac7e80e31d30f81cb6bb1 from the intel-2008-q4 branch libdrm: 2.4.3+git+20090105+a8c5480 from Debian experimental xserver: 1.5.3 from Debian experimental glxgears still shows only a black window. However, in dmesg, I found this: [drm] Initialized i915 1.6.0 20080730 on minor 0 mtrr: no MTRR for 8000,1000 found mtrr: no MTRR for 8000,1000 found mtrr: no MTRR for 8000,1000 found [ cut here ] WARNING: at /home/scorpion/src/kernel/git/linux-2.6-drm-intel/drivers/gpu/drm/i915/i915_gem.c:2475 / i915_gem_idle+0x380/0x3a0 [i915]() Modules linked in: i915 drm hci_usb rfcomm l2cap bluetooth dm_crypt / dm_mod firewire_sbp2 arc4 ecb usblp ath5k mac80211 snd_hda_intel / firewire_ohci firewire_core cfg80211 crc_itu_t sky2 Pid: 3093, comm: Xorg Not tainted 2.6.28-6-ge1a6fce #1 Call Trace: [] warn_on_slowpath+0x5f/0xa0 [] mntput_no_expire+0x18/0xf0 [] drm_gem_object_free+0x0/0x50 [drm] [] i915_gem_retire_requests+0xf7/0x150 [i915] [] i915_gem_idle+0x380/0x3a0 [i915] [] i915_gem_leavevt_ioctl+0x11/0x30 [i915] [] drm_ioctl+0xee/0x2f0 [drm] [] i915_gem_leavevt_ioctl+0x0/0x30 [i915] [] vfs_ioctl+0x78/0x90 [] do_vfs_ioctl+0x67/0x4c0 [] vfs_write+0x102/0x140 [] sys_ioctl+0x3d/0x70 [] sysenter_do_call+0x12/0x25 ---[ end trace f8a68b832e7da9a5 ]--- mtrr: no MTRR for 8000,1000 found mtrr: no MTRR for 8000,1000 found mtrr: no MTRR for 8000,1000 found mtrr: no MTRR for 8000,1000 found Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-savage: add missing xf86CrtcConfigInit in SavagePreInit
Alex Deucher escribió:
> On Tue, Jan 13, 2009 at 11:36 AM, Alex Villacís Lasso
> wrote:
>
>> With the latest git for xserver and the latest git for savage, an attempt to
>> start up crashes the server unless this patch is applied. It seems that an
>> explicit xf86CrtcConfigInit() is now required in the PreInit stage of the
>> driver setup. I found via valgrind that the absence of this call causes
>> several invalid reads, but only the one triggered by DRIFinishScreenInit()
>> actually crashes the server on startup. Grepping through the git code, only
>> xf86-video-intel, xf86-video-ati, xf86-video-nv and xf86-video-siliconmotion
>> have this call in their code. Does this mean that any other driver that
>> tries to init DRI will crash in the same way with latest xserver?
>>
>
> These just all happen to be drivers with xrandr 1.2 support.
> Something changed in the xserver that breaks non xrandr 1.2 drivers.
> You should probably file a bug (https://bugs.freedesktop.org) and make
> sure this gets fixed before xserver 1.6 ships.
>
> Alex
>
>
Bug #19539 has been opened with the proposed patch.
--
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel GM45: Loop of continuously triggered output detections
On Tue, 2009-01-13 at 09:08 -0800, Jesse Barnes wrote: > On Tuesday, January 13, 2009 6:58 am Peter Clifton wrote: > > On Tue, 2009-01-13 at 17:26 +0800, Jin, Gordon wrote: > > > Peter Clifton wrote on Tuesday, January 13, 2009 11:45 AM: > > > > On Tue, 2009-01-13 at 01:55 +, Peter Clifton wrote: > > > >> Testing git HEAD intel drivers, also recent Xorg: > > > >> > > > >> > > > >> After the problem with miss-detected TV-out, I killed Xorg with a > > > >> Ctrl +Alt+Backspace (I've got zapping re-enabled in my xorg.conf), > > > >> and the outputs detected properly, with no TV output detected as > > > >> being connected. > > > >> > > > >> The performance was very slow, however, and with the characteristic > > > >> "jiggle" / jittering of the mouse cursor position which I've > > > > > > noticed > > > > > > >> on both my Intel based machines during output detection. > > > >> > > > >> Trying xrandr, adjusting brightness, had no effect. A couple of VT > > > >> switches to VT1 and back to Xorg finally stopped the detection > > > > > > loop, > > > > > > >> although during that process, one of the the switches to VT1 left > > > > > > me > > > > > > >> with a corrupted console. (Possibly scanning out from the wrong > > > > > > part > > > > > > >> of the frame-buffer, perhaps with the wrong sync settings?). > > > >> > > > >> I've attached the log. It does show a page-table problem with the > > > >> last VT switch. > > > > > > > > I managed to re-trigger this bug by pulling the laptop's AC power > > > > adaptor out, and plugging it back in again. I suspect either an ACPI > > > > event, or something inside HP's SMM BIOS code triggered it. My old > > > > > > HP > > > > > > > nc 6320 didn't properly respect _DOS bit 4, so would always fiddle > > > > with the graphics hardware when you plugged / unplugged the AC > > > > adaptor. > > > > > > > > I've not dug deeply into this one, so I'm not quite blaming the BIOS > > > > yet, however it is looking somewhat guilty. > > > > > > This looks similar to > > > http://bugs.freedesktop.org/show_bug.cgi?id=19431, interesting bug. > > > > It only bears very supercficial similarities as far as I can see. > > > > Yes, I had a problem with intermittent TV out detection, but that > > doesn't appear to be dependent on battery state. > > > > My problem is that "something" (often triggered by an AC state change, > > but sometimes just when I boot up) is triggering a storm of probes to > > detect outputs. I did wonder if this might be due to a faulty detection > > routine trying to spot that I inserted a cable in one of the outputs, > > however this backtrace I grabbed whilst the problem was occuring > > suggests that it is being dispatched through the X server: > > > > #0 0xb809e430 in __kernel_vsyscall () > > #1 0xb7ce7700 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6 > > #2 0xb7d24ffc in usleep () from /lib/tls/i686/cmov/libc.so.6 > > #3 0xb7ab826e in i830WaitForVblank (pScreen=0xa197040) at > > ../../src/i830_display.c:379 #4 0xb7abaf80 in i830_crtc_mode_set > > (crtc=0xa199b80, mode=0xbfdb9ea0, adjusted_mode=0xa4d70e8, x=0, y=0) at > > ../../src/i830_display.c:1511 #5 0x080ed08d in xf86CrtcSetModeTransform > > (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=1, transform=0x0, x=0, y=0) at > > ../../../../hw/xfree86/modes/xf86Crtc.c:366 > > #6 0x080ed6d6 in xf86CrtcSetMode (crtc=0xa199b80, mode=0xbfdb9ea0, > > rotation=8180, x=0, y=0) at ../../../../hw/xfree86/modes/xf86Crtc.c:413 #7 > > 0xb7ab956d in i830GetLoadDetectPipe (output=0xa19b618, mode=0xbfdb9ea0, > > dpms_mode=0xbfdb9f78) at ../../src/i830_display.c:1811 #8 0xb7ad746d in > > i830_tv_detect (output=0xa19b618) at ../../src/i830_tv.c:1376 #9 > > 0x080eda90 in xf86ProbeOutputModes (scrn=0xa197040, maxX=4096, maxY=4096) > > at ../../../../hw/xfree86/modes/xf86Crtc.c:1500 #10 0x080f56c0 in > > xf86RandR12GetInfo12 (pScreen=0xa19c460, rotations=0xbfdba16a) at > > ../../../../hw/xfree86/modes/xf86RandR12.c:1255 #11 0x08162e89 in RRGetInfo > > (pScreen=0xa19c460) at ../../randr/rrinfo.c:196 #12 0x08167084 in > > ProcRRGetScreenSizeRange (client=0xa3d2208) at ../../randr/rrscreen.c:227 > > #13 0x0815f305 in ProcRRDispatch (client=0x0) at ../../randr/randr.c:473 > > #14 0x0808cdbf in Dispatch () at ../../dix/dispatch.c:437 > > #15 0x08071aad in main (argc=10, argv=0xbfdba324, envp=Cannot access memory > > at address 0x8 ) at ../../dix/main.c:383 > > > > > > Does anyone know if there is an easy way to ascertain from a backtrace, > > which client caused a particular dispatch? (Perhaps chasing back > > through /proc/ or netstat to find out more info on the actual process > > involved? > > Well, the randr functions are in the backtrace, so it's possible some > application is triggering the re-probe. That doesn't mean your BIOS isn't > causing trouble though: it could be sending ACPI events that are getting > picked up by some app which is then doing a re-probe. You should be able to > check out your ACPI daemon
Re: xf86-video-savage: add missing xf86CrtcConfigInit in SavagePreInit
On Tue, 2009-01-13 at 12:28 -0500, Alex Deucher wrote: > These just all happen to be drivers with xrandr 1.2 support. > Something changed in the xserver that breaks non xrandr 1.2 drivers. > You should probably file a bug (https://bugs.freedesktop.org) and make > sure this gets fixed before xserver 1.6 ships. I posted a proposed patch to bug 19337; please give that a try and see if it fixes the bug for you. Then fix the driver to support RandR 1.2. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-savage: add missing xf86CrtcConfigInit in SavagePreInit
On Tue, Jan 13, 2009 at 11:36 AM, Alex Villacís Lasso wrote: > With the latest git for xserver and the latest git for savage, an attempt to > start up crashes the server unless this patch is applied. It seems that an > explicit xf86CrtcConfigInit() is now required in the PreInit stage of the > driver setup. I found via valgrind that the absence of this call causes > several invalid reads, but only the one triggered by DRIFinishScreenInit() > actually crashes the server on startup. Grepping through the git code, only > xf86-video-intel, xf86-video-ati, xf86-video-nv and xf86-video-siliconmotion > have this call in their code. Does this mean that any other driver that > tries to init DRI will crash in the same way with latest xserver? These just all happen to be drivers with xrandr 1.2 support. Something changed in the xserver that breaks non xrandr 1.2 drivers. You should probably file a bug (https://bugs.freedesktop.org) and make sure this gets fixed before xserver 1.6 ships. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel GM45: Loop of continuously triggered output detections
On Tuesday, January 13, 2009 6:58 am Peter Clifton wrote: > On Tue, 2009-01-13 at 17:26 +0800, Jin, Gordon wrote: > > Peter Clifton wrote on Tuesday, January 13, 2009 11:45 AM: > > > On Tue, 2009-01-13 at 01:55 +, Peter Clifton wrote: > > >> Testing git HEAD intel drivers, also recent Xorg: > > >> > > >> > > >> After the problem with miss-detected TV-out, I killed Xorg with a > > >> Ctrl +Alt+Backspace (I've got zapping re-enabled in my xorg.conf), > > >> and the outputs detected properly, with no TV output detected as > > >> being connected. > > >> > > >> The performance was very slow, however, and with the characteristic > > >> "jiggle" / jittering of the mouse cursor position which I've > > > > noticed > > > > >> on both my Intel based machines during output detection. > > >> > > >> Trying xrandr, adjusting brightness, had no effect. A couple of VT > > >> switches to VT1 and back to Xorg finally stopped the detection > > > > loop, > > > > >> although during that process, one of the the switches to VT1 left > > > > me > > > > >> with a corrupted console. (Possibly scanning out from the wrong > > > > part > > > > >> of the frame-buffer, perhaps with the wrong sync settings?). > > >> > > >> I've attached the log. It does show a page-table problem with the > > >> last VT switch. > > > > > > I managed to re-trigger this bug by pulling the laptop's AC power > > > adaptor out, and plugging it back in again. I suspect either an ACPI > > > event, or something inside HP's SMM BIOS code triggered it. My old > > > > HP > > > > > nc 6320 didn't properly respect _DOS bit 4, so would always fiddle > > > with the graphics hardware when you plugged / unplugged the AC > > > adaptor. > > > > > > I've not dug deeply into this one, so I'm not quite blaming the BIOS > > > yet, however it is looking somewhat guilty. > > > > This looks similar to > > http://bugs.freedesktop.org/show_bug.cgi?id=19431, interesting bug. > > It only bears very supercficial similarities as far as I can see. > > Yes, I had a problem with intermittent TV out detection, but that > doesn't appear to be dependent on battery state. > > My problem is that "something" (often triggered by an AC state change, > but sometimes just when I boot up) is triggering a storm of probes to > detect outputs. I did wonder if this might be due to a faulty detection > routine trying to spot that I inserted a cable in one of the outputs, > however this backtrace I grabbed whilst the problem was occuring > suggests that it is being dispatched through the X server: > > #0 0xb809e430 in __kernel_vsyscall () > #1 0xb7ce7700 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7d24ffc in usleep () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7ab826e in i830WaitForVblank (pScreen=0xa197040) at > ../../src/i830_display.c:379 #4 0xb7abaf80 in i830_crtc_mode_set > (crtc=0xa199b80, mode=0xbfdb9ea0, adjusted_mode=0xa4d70e8, x=0, y=0) at > ../../src/i830_display.c:1511 #5 0x080ed08d in xf86CrtcSetModeTransform > (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=1, transform=0x0, x=0, y=0) at > ../../../../hw/xfree86/modes/xf86Crtc.c:366 > #6 0x080ed6d6 in xf86CrtcSetMode (crtc=0xa199b80, mode=0xbfdb9ea0, > rotation=8180, x=0, y=0) at ../../../../hw/xfree86/modes/xf86Crtc.c:413 #7 > 0xb7ab956d in i830GetLoadDetectPipe (output=0xa19b618, mode=0xbfdb9ea0, > dpms_mode=0xbfdb9f78) at ../../src/i830_display.c:1811 #8 0xb7ad746d in > i830_tv_detect (output=0xa19b618) at ../../src/i830_tv.c:1376 #9 > 0x080eda90 in xf86ProbeOutputModes (scrn=0xa197040, maxX=4096, maxY=4096) > at ../../../../hw/xfree86/modes/xf86Crtc.c:1500 #10 0x080f56c0 in > xf86RandR12GetInfo12 (pScreen=0xa19c460, rotations=0xbfdba16a) at > ../../../../hw/xfree86/modes/xf86RandR12.c:1255 #11 0x08162e89 in RRGetInfo > (pScreen=0xa19c460) at ../../randr/rrinfo.c:196 #12 0x08167084 in > ProcRRGetScreenSizeRange (client=0xa3d2208) at ../../randr/rrscreen.c:227 > #13 0x0815f305 in ProcRRDispatch (client=0x0) at ../../randr/randr.c:473 > #14 0x0808cdbf in Dispatch () at ../../dix/dispatch.c:437 > #15 0x08071aad in main (argc=10, argv=0xbfdba324, envp=Cannot access memory > at address 0x8 ) at ../../dix/main.c:383 > > > Does anyone know if there is an easy way to ascertain from a backtrace, > which client caused a particular dispatch? (Perhaps chasing back > through /proc/ or netstat to find out more info on the actual process > involved? Well, the randr functions are in the backtrace, so it's possible some application is triggering the re-probe. That doesn't mean your BIOS isn't causing trouble though: it could be sending ACPI events that are getting picked up by some app which is then doing a re-probe. You should be able to check out your ACPI daemon log or use acpi_listen to see if that's happening. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: version > 6.9.0 does not work on Lenovo T400 when docked
Dave Airlie wrote: >> Should I file a bug in the bugzilla? Is this even the right place to >> ask? If not, then I would be happy to get a pointer in the right direction. > please file a bug in bugzilla against xorg, Driver/radeon (or maybe > ati), attach xorg log from 6.9.0 and new driver if possible. Thanks! I will when I find the time. > Dave. Best, Sascha ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft XI 2 protocol specification
On Tue, 2009-01-13 at 22:37 +1000, Peter Hutterer wrote: > The idea here was to be able to filter easily. I expect that many clients > won't care much about reattachment, but they would care about new MDs. > Having this information may prove useful. As for the deviceids - same idea. I guess this kinda depends on how we expect to implement things on the client side. If we want to mirror the server device hierarchy in the client library, it might be easier to just take the 'something changed' event and reconstruct the whole client state than attempt to patch things with incremental data. Dunno. > Not having this state makes us prone for race conditions. Class changes are > expected to happen often, and a different XDCE may be generated while the > request is waiting to be processed. In this case, the client cannot process > events with the correct axis information. > At least for XDCE, it is mandatory that the new information is part of the > event. XDHCE is less frequent, justifying the query. Less frequent doesn't mean non-racy though; we've had this problem with X key mapping forever, and worse now that keymap notify events are happening more often. > > Send these in floating point so we capture sub-pixel positions > > trivially? > > ok. Or perhaps fixed point? That eliminates problems with different precision in different parts of the screen. > > Uh. What about absolute devices? Can those send XRelativeMotionEvents? > > If so, this seems more like an XIDeviceRawEvent. > > (same comments about last_* apply here) > > Good point. I will revise. Oh, are these INT32 here (for relative devices)? And, if so, do we use INT32 in the non-raw event for consistency? > I don't have an answer for all that yet and it strikes me as one of those > things that just need testing to see what works best. Ok, sounds like we need to figure out how grabs work for devices which are both pointer and keyboard then. I can't, frankly, think of a better way than having them appear as two logical SDs. Which leaves us with slightly weird event delivery, but that seems better than complicated grab semantics? > The main point of input classes in XI2 would be to specifiy capabilities in > detail. Some of the input classes aren't particularly great for that so they > could do with a redesign. Example here is the ValuatorInfo that only allows > for a single state across all axes. With the above discussion, it seems like SDs are either 'pointer' or 'keyboard' devices, and beyond that, they've got a collection of keys or buttons/axes. Making sure the per-axis information isn't constrained by some global device information seems like a requirement here. > Current deviceids are CARD8, so CARD32 would still require a reimplementation. > Now, at least for XI2 this may not be a problem as we could decide the upper > 24 bit as "reserved for future use" and continue to only use 8 bits in > requests and replies - until those are reimplemented at a later point in time. I guess I don't see any huge 're-implementation' here -- you're just widening a data type. It may cause a flag-day for input devices, but we've been there before. > 16 bit ids were chosen mainly because the fit nicely after the event type in > the GenericEvent. Before we run out of 2^16 deviceids per X server, we run > into other issues anyway. Ok, seems fairly reasonable. > XI valuators are already 32 bits, and we probably shouldn't scale down. > we accept integer-only format in the valuator Right, so we use 16.16 fixed point for their screen coordinates then and get plenty of sub-pixel position. > Another thing discussed briefly was the use of a separate format internal to > the server, i.e. the XI events are assembled at delivery time, not carried > through the server. This is an implementation detail though and shouldn't be > too hard to support. Hmm. With the generic event stuff fixing the list-of-events disaster, is there some other format you'd prefer? Adding a gratuitous data type doesn't seem like a winning plan here. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-savage: add missing xf86CrtcConfigInit in SavagePreInit
With the latest git for xserver and the latest git for savage, an
attempt to start up crashes the server unless this patch is applied. It
seems that an explicit xf86CrtcConfigInit() is now required in the
PreInit stage of the driver setup. I found via valgrind that the absence
of this call causes several invalid reads, but only the one triggered by
DRIFinishScreenInit() actually crashes the server on startup. Grepping
through the git code, only xf86-video-intel, xf86-video-ati,
xf86-video-nv and xf86-video-siliconmotion have this call in their code.
Does this mean that any other driver that tries to init DRI will crash
in the same way with latest xserver?
Changelog:
* Add missing xf86CrtcConfigInit in SavagePreInit. Fixes a crash on
startup with latest xserver git.
--
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
>From 9d7b0817f754fb5c03ef1af60443de3943ebd0a3 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?=
Date: Mon, 12 Jan 2009 23:56:12 -0500
Subject: [PATCH] Add missing xf86CrtcConfigInit call on SavagePreInit. Fixes server crash on startup with latest xserver git.
---
src/savage_driver.c | 14 ++
src/savage_driver.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/savage_driver.c b/src/savage_driver.c
index da472e9..d2954c3 100644
--- a/src/savage_driver.c
+++ b/src/savage_driver.c
@@ -1249,6 +1249,18 @@ static void SavageGetPanelInfo(ScrnInfoPtr pScrn)
}
}
+static Bool
+SavageCRTCResize(ScrnInfoPtr scrn, int width, int height)
+{
+scrn->virtualX = width;
+scrn->virtualY = height;
+return TRUE;
+}
+
+static const xf86CrtcConfigFuncsRec SavageCRTCResizeFuncs = {
+SavageCRTCResize
+};
+
static Bool SavagePreInit(ScrnInfoPtr pScrn, int flags)
{
@@ -1888,6 +1900,8 @@ static Bool SavagePreInit(ScrnInfoPtr pScrn, int flags)
/* Add more options here. */
+ /* Allocate an xf86CrtcConfig */
+xf86CrtcConfigInit (pScrn, &SavageCRTCResizeFuncs);
psav = SAVPTR(pScrn);
psav->IsSecondary = FALSE;
diff --git a/src/savage_driver.h b/src/savage_driver.h
index c47b472..1db429a 100644
--- a/src/savage_driver.h
+++ b/src/savage_driver.h
@@ -65,6 +65,7 @@
#include "xaa.h"
#include "exa.h"
#include "xf86xv.h"
+#include "xf86Crtc.h"
#include "savage_regs.h"
#include "savage_vbe.h"
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Does X.org 7.4 work with Mesa 7.2?
Jeremy Henty wrote: > On Mon, Jan 12, 2009 at 01:23:40PM +0200, Angel Tsankov wrote: >> ... However, I stumbled upon another problem and started a new >> thread on this list. Here's a link to it: >> http://lists.freedesktop.org/archives/xorg/2009-January/042364.html > > I am afraid I don't have any ideas for this one. Good luck! > Could it be that GCC is too old (3.4.3)? --Angel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel GM45: Loop of continuously triggered output detections
This didn't send first time On Tue, 2009-01-13 at 01:55 +, Peter Clifton wrote: > Testing git HEAD intel drivers, also recent Xorg: > > > After the problem with miss-detected TV-out, I killed Xorg with a Ctrl > +Alt+Backspace (I've got zapping re-enabled in my xorg.conf), and the > outputs detected properly, with no TV output detected as being > connected. > > The performance was very slow, however, and with the characteristic > "jiggle" / jittering of the mouse cursor position which I've noticed on > both my Intel based machines during output detection. > > Trying xrandr, adjusting brightness, had no effect. A couple of VT > switches to VT1 and back to Xorg finally stopped the detection loop, > although during that process, one of the the switches to VT1 left me > with a corrupted console. (Possibly scanning out from the wrong part of > the frame-buffer, perhaps with the wrong sync settings?). > > I've attached the log. It does show a page-table problem with the last > VT switch. I managed to re-trigger this bug by pulling the laptop's AC power adaptor out, and plugging it back in again. I suspect either an ACPI event, or something inside HP's SMM BIOS code triggered it. My old HP nc 6320 didn't properly respect _DOS bit 4, so would always fiddle with the graphics hardware when you plugged / unplugged the AC adaptor. I've not dug deeply into this one, so I'm not quite blaming the BIOS yet, however it is looking somewhat guilty. > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel GM45: Loop of continuously triggered output detections
This didn't send first time... On Tue, 2009-01-13 at 01:55 +, Peter Clifton wrote: > Trying xrandr, adjusting brightness, had no effect. A couple of VT > switches to VT1 and back to Xorg finally stopped the detection loop, > although during that process, one of the the switches to VT1 left me > with a corrupted console. (Possibly scanning out from the wrong part of > the frame-buffer, perhaps with the wrong sync settings?). I've since reproduced this effect, and I took a video showing what the corruption looks like. I'll send it to anyone interested. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Intel GM45: Loop of continuously triggered output detections
On Tue, 2009-01-13 at 17:26 +0800, Jin, Gordon wrote: > Peter Clifton wrote on Tuesday, January 13, 2009 11:45 AM: > > On Tue, 2009-01-13 at 01:55 +, Peter Clifton wrote: > >> Testing git HEAD intel drivers, also recent Xorg: > >> > >> > >> After the problem with miss-detected TV-out, I killed Xorg with a > >> Ctrl +Alt+Backspace (I've got zapping re-enabled in my xorg.conf), > >> and the outputs detected properly, with no TV output detected as > >> being connected. > >> > >> The performance was very slow, however, and with the characteristic > >> "jiggle" / jittering of the mouse cursor position which I've > noticed > >> on both my Intel based machines during output detection. > >> > >> Trying xrandr, adjusting brightness, had no effect. A couple of VT > >> switches to VT1 and back to Xorg finally stopped the detection > loop, > >> although during that process, one of the the switches to VT1 left > me > >> with a corrupted console. (Possibly scanning out from the wrong > part > >> of the frame-buffer, perhaps with the wrong sync settings?). > >> > >> I've attached the log. It does show a page-table problem with the > >> last VT switch. > > > > I managed to re-trigger this bug by pulling the laptop's AC power > > adaptor out, and plugging it back in again. I suspect either an ACPI > > event, or something inside HP's SMM BIOS code triggered it. My old > HP > > nc 6320 didn't properly respect _DOS bit 4, so would always fiddle > > with the graphics hardware when you plugged / unplugged the AC > > adaptor. > > > > I've not dug deeply into this one, so I'm not quite blaming the BIOS > > yet, however it is looking somewhat guilty. > > This looks similar to > http://bugs.freedesktop.org/show_bug.cgi?id=19431, interesting bug. It only bears very supercficial similarities as far as I can see. Yes, I had a problem with intermittent TV out detection, but that doesn't appear to be dependent on battery state. My problem is that "something" (often triggered by an AC state change, but sometimes just when I boot up) is triggering a storm of probes to detect outputs. I did wonder if this might be due to a faulty detection routine trying to spot that I inserted a cable in one of the outputs, however this backtrace I grabbed whilst the problem was occuring suggests that it is being dispatched through the X server: #0 0xb809e430 in __kernel_vsyscall () #1 0xb7ce7700 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7d24ffc in usleep () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7ab826e in i830WaitForVblank (pScreen=0xa197040) at ../../src/i830_display.c:379 #4 0xb7abaf80 in i830_crtc_mode_set (crtc=0xa199b80, mode=0xbfdb9ea0, adjusted_mode=0xa4d70e8, x=0, y=0) at ../../src/i830_display.c:1511 #5 0x080ed08d in xf86CrtcSetModeTransform (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=1, transform=0x0, x=0, y=0) at ../../../../hw/xfree86/modes/xf86Crtc.c:366 #6 0x080ed6d6 in xf86CrtcSetMode (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=8180, x=0, y=0) at ../../../../hw/xfree86/modes/xf86Crtc.c:413 #7 0xb7ab956d in i830GetLoadDetectPipe (output=0xa19b618, mode=0xbfdb9ea0, dpms_mode=0xbfdb9f78) at ../../src/i830_display.c:1811 #8 0xb7ad746d in i830_tv_detect (output=0xa19b618) at ../../src/i830_tv.c:1376 #9 0x080eda90 in xf86ProbeOutputModes (scrn=0xa197040, maxX=4096, maxY=4096) at ../../../../hw/xfree86/modes/xf86Crtc.c:1500 #10 0x080f56c0 in xf86RandR12GetInfo12 (pScreen=0xa19c460, rotations=0xbfdba16a) at ../../../../hw/xfree86/modes/xf86RandR12.c:1255 #11 0x08162e89 in RRGetInfo (pScreen=0xa19c460) at ../../randr/rrinfo.c:196 #12 0x08167084 in ProcRRGetScreenSizeRange (client=0xa3d2208) at ../../randr/rrscreen.c:227 #13 0x0815f305 in ProcRRDispatch (client=0x0) at ../../randr/randr.c:473 #14 0x0808cdbf in Dispatch () at ../../dix/dispatch.c:437 #15 0x08071aad in main (argc=10, argv=0xbfdba324, envp=Cannot access memory at address 0x8 ) at ../../dix/main.c:383 Does anyone know if there is an easy way to ascertain from a backtrace, which client caused a particular dispatch? (Perhaps chasing back through /proc/ or netstat to find out more info on the actual process involved? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [libXi PATCH] Be smarter about generating man pages
On Mon, Jan 12, 2009 at 5:31 PM, Peter Hutterer wrote: > On Tue, Dec 16, 2008 at 04:45:16PM -0800, Dan Nicholson wrote: >> With the current rules, the man pages will be generated repeatedly if you >> have xmlto installed. This is because make always thinks they are out of >> date with respect to their prerequisite, do_xmlto_stage. They are changed >> here to handle the multiple output files as described in the automake >> manual. >> >> distcheck has been confirmed to still work such that building from the >> tarball does not require xmlto. On the other hand, if the user wants to >> rebuild the man pages, they'll have to explicitly touch XI.xml. >> >> It may be better to split the xml into per-page files so that xmlto only >> generates one output at a time. A toplevel XI.xml can still pull together >> all the pieces with XInclude. >> --- >> man/.gitignore |2 + >> man/Makefile.am | 143 >> +-- >> 2 files changed, 77 insertions(+), 68 deletions(-) > > Late, but nonetheless. Pushed as 9911b7846ca2cedf08a963c84efe7907438975c1. > Thanks for the patch. Thanksl. What do you think about splitting up the XML? http://people.freedesktop.org/~dbn/libXi-manpages.patch -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft XI 2 protocol specification
First, thanks for the comments.
On Mon, Jan 12, 2009 at 11:09:22PM -0800, Keith Packard wrote:
> On Tue, 2009-01-13 at 16:46 +1000, Peter Hutterer wrote:
>
> > An XDeviceHierarchyChangedEvent is sent whenever the device hierarchy
> > has
> > been changed by either the client, or by server-internal events. The
> > flags
> > specify all types of hierarchy modifiations that have occured.
> > Clients are expected to query the server for the new hierarchy.
>
> If clients need to take another round-trip, why pack any info into this
> event other than the 'something changed' bit? Presumably this doesn't
> happen very often, right?
The idea here was to be able to filter easily. I expect that many clients
won't care much about reattachment, but they would care about new MDs.
Having this information may prove useful. As for the deviceids - same idea.
> Alternatively, pack the whole change into the event?
>
> > Classes is a list of input device classes that are now provided by the
> > device, see XI 1.x specification for more details.
>
> Similarly, any reason to not just have the client download the new
> device state after it receives this event?
>
> A viable answer here might be that placing the data in events instead of
> later replies is that clients can correctly parse the intervening event
> stream. This doesn't apply to XDHCE events above as clients must query
> state anyway.
Not having this state makes us prone for race conditions. Class changes are
expected to happen often, and a different XDCE may be generated while the
request is waiting to be processed. In this case, the client cannot process
events with the correct axis information.
At least for XDCE, it is mandatory that the new information is part of the
event. XDHCE is less frequent, justifying the query.
> > root, event, child are the root window, event window or subwindow,
> > respectively. See core protocol spec for more detail.
> > root_x, root_y is the position of the pointer in screen coordinates
> > event_x, event_y is the position of the pointer in screen coordinates
> > relative to the event window.
>
> Send these in floating point so we capture sub-pixel positions
> trivially?
ok.
> > last_button is the highest bit set in buttons and determines the size of
> > buttons.
> > last_modifier is the highest bit set in modifiers and determines the
> > size
> > of modifiers.
> > last_valuator is the highest bit set in valuators and determines the
> > size
> > of valuators
>
> Clients are likely to decode this incorrectly as you have to be careful
> about all of these. Any reason to not just indicate the length of each
> bit vector in 32-bit units?
That works too, and makes the coding a bit easer.
> > axisvalues specifies the current value of the valuator in it's current
> > mode (relative or absolute).
>
> I assume the native values for all devices are integers?
correct, they are traditionally CARD32.
> > Relative Motion event.
> > type is XI_RelativeMotion
> > This event is sent regardless of clipping and always provides the
> > device-specific data. Pointer acceleration does not affect the axis
> > values.
>
> Uh. What about absolute devices? Can those send XRelativeMotionEvents?
> If so, this seems more like an XIDeviceRawEvent.
> (same comments about last_* apply here)
Good point. I will revise.
> > ┌───
> > XIPresence
> > GENERICEVENTDATA
> > devchange: SETofDEVICECHANGE
> > control:CARD16
> > └───
> >
> > DEVICECHANGE { DeviceAdded, DeviceRemoved, DeviceEnabled,
> > DeviceDisabled,
> >DeviceControlChanged }
> >
> > DevicePresence event, equivalent to the XI 1.4 event.
> > type is XI_PresenceNotify
> > devchange specifies the type of device change that has occured. If
> > devchange is DeviceControlChanged, control specifies the ID of the
> > device
> > control that has changed. Otherwise, control is unspecified.
> >
> > The length of a Presence event is always 0.
>
> How about describing this event in detail, rather than saying 'Like XI
> 1.4, except'. Keeping the XI 2 spec stand-alone would reduce the amount
> of reading when learning how to do input.
This is what I plan for the final version. This is the first draft (and half
of it was transcoded from code for this email), so I try to keep the amount of
typing down. FWIW, Presence events are in fact exactly the same as the 1.4
ones, bar the differnet wire format of course.
> > - this isn't fixing the problem we have with devices that are both pointers
> > and keyboards
>
> So make all devices both pointers and keyboards and have XIDeviceEvent
> include keys as well as buttons.
The best way to go about this is to have a single MD instead of a separate MD
pointer and an MD keyboard. However, core re
Re: DESTDIR and pkg-config variables
On Mon, 12 Jan 2009, Dan Nicholson wrote:
On Mon, Jan 12, 2009 at 10:21 AM, Paulo César Pereira de Andrade
wrote:
Thanks. For simplicity, I feel tempted to remove:
PKG_CHECK_MODULES(APPDEFS, xt)
appdefaultdir=$(pkg-config --variable=appdefaultdir xt)
AC_SUBST(appdefaultdir)
from configure.ac, and "hardcode" Makefile.am to:
appdefaultdir = $(datadir)/X11/app-defaults
If you're going to hardcode it in Makefile.am, then there's no reason
to do any checking or substituting in configure.
This mainly, because in my computer I have "app-defaults"
directories in:
/etc/X11/app-defaults
/etc/X11//app-defaults
/usr/X11R6/lib/X11/app-defaults
/usr/share/apps/kdisplay/app-defaults
/usr/share/app-defaults
/usr/share/X11/app-defaults
/usr/lib/app-defaults
/usr/lib/X11/app-defaults
/opt/kde3/share/apps/kdisplay/app-defaults
/usr/lib//app-defaults
Sure, but there should really only be one directory where packages
drop their app-defaults. That's what's exposed in $PKG_CONFIG
--variable=appdefaultdir xt. Especially since you can build libXt to
have its search path be anything you want. Hardcoding
$(datadir)/X11/app-defaults completely defeats the purpose of that.
The GNU coding standards state more or less explicitly that ALL installation
directories ought to derive from ${prefix}, and any violation of that most
probably interferes with distcheck.
Even "configure --prefix=FOO --exec-prefix=FOO/ARCH" is bad, that ought
to be "configure --prefix=FOO --exec-prefix='${prefix}'/ARCH".
What I have seen in several packages is, however, this:
If $prefix==/usr and and $sysconfdir==/usr/etc, then (and only then) they
substitute sysconfdir=/etc.
In the same spirit one might proceed as follows:
If the string "$PKG_CONFIG --variable=prefix xt" is a prefix of the string
"$PKG_CONFIG --variable=appdefaultdir xt", then (and only then) replace that
prefix by '${prefix}'. This will then be compatible with distcheck!
regards
Peter Breitenlohner ___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to write an X driver..?
On Mon, Jan 12, 2009 at 03:23:48PM +0100, Stephane Marchesin wrote: > On Mon, Jan 12, 2009 at 14:35, Florian Echtler wrote: > > But can you explain "shadowfb approach" in more detail? I've seen the > > phrase in the fbdrv manual already; does that mean that the X driver > > maintains a copy of the framebuffer content in memory and only tries to > > transmit changed regions? > > Yes shadowfb does just that. A couple of drivers implement it, look at > nv or radeon for example. On the plus side you get a very small driver > and you just have to implement a copy hook, the regions are determined > by the X server for you. Or avivo is a much more simple example. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.5.99.2
Jin, Gordon wrote: > Please let me know if any questions. What's about the combination XvMC + UXA on 915/945? That seems not to work, can we expect that back? Cheers, Johannes ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: version > 6.9.0 does not work on Lenovo T400 when docked
On Tue, Jan 13, 2009 at 8:31 AM, Sascha Steinbiss wrote: > Hi everyone, > > I am unsure where to turn to in this matter, but it seems I have > encountered an issue in the current version of the xf86-video-ati module. > > I have a Lenovo T400 with a "ATI Technologies Inc Mobility Radeon HD > 3400 Series rev 0" graphics chip. Usually I boot up with the machine in > the dock, and use the DVI output there to drive a Samsung 24" display > (multi-head via xrandr). > > Version 6.9.0 works like a charm (though unaccelerated). However, using > any later version (tested with the 6.9.0.91 and 6.10.0 versions from the > Arch testing repository), when I boot up with the laptop docked all X > does is cycle through uniformly colored full screens on the internal > display (white->red->green->blue->grey->vertical black/white > gradient->horizontal black/white gradient), and the external DVI output > is ignored. The same happens when I boot up undocked, then put the > laptop in the dock and use xrandr to enable the DVI out. > > I attach my xorg.conf for debugging. Do you need any more information? > Should I file a bug in the bugzilla? Is this even the right place to > ask? If not, then I would be happy to get a pointer in the right direction. > please file a bug in bugzilla against xorg, Driver/radeon (or maybe ati), attach xorg log from 6.9.0 and new driver if possible. Dave. > Thanks a lot in advance, > Sascha > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Intel GM45: Loop of continuously triggered output detections
Peter Clifton wrote on Tuesday, January 13, 2009 11:45 AM: > On Tue, 2009-01-13 at 01:55 +, Peter Clifton wrote: >> Testing git HEAD intel drivers, also recent Xorg: >> >> >> After the problem with miss-detected TV-out, I killed Xorg with a >> Ctrl +Alt+Backspace (I've got zapping re-enabled in my xorg.conf), >> and the outputs detected properly, with no TV output detected as >> being connected. >> >> The performance was very slow, however, and with the characteristic >> "jiggle" / jittering of the mouse cursor position which I've noticed >> on both my Intel based machines during output detection. >> >> Trying xrandr, adjusting brightness, had no effect. A couple of VT >> switches to VT1 and back to Xorg finally stopped the detection loop, >> although during that process, one of the the switches to VT1 left me >> with a corrupted console. (Possibly scanning out from the wrong part >> of the frame-buffer, perhaps with the wrong sync settings?). >> >> I've attached the log. It does show a page-table problem with the >> last VT switch. > > I managed to re-trigger this bug by pulling the laptop's AC power > adaptor out, and plugging it back in again. I suspect either an ACPI > event, or something inside HP's SMM BIOS code triggered it. My old HP > nc 6320 didn't properly respect _DOS bit 4, so would always fiddle > with the graphics hardware when you plugged / unplugged the AC > adaptor. > > I've not dug deeply into this one, so I'm not quite blaming the BIOS > yet, however it is looking somewhat guilty. This looks similar to http://bugs.freedesktop.org/show_bug.cgi?id=19431, interesting bug. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: [ANNOUNCE] xf86-video-intel 2.5.99.2
Tino Keitel wrote on Friday, January 09, 2009 3:45 AM: > On Thu, Jan 08, 2009 at 16:04:55 +0800, Zhenyu Wang wrote: >> >> Subject: [ANNOUNCE] xf86-video-intel 2.5.99.2 > > I'd like to know how/what can/should be tested before the release. > What versions of kernel/xserver/mesa/drm/whatever are required? And > for what features (XvMC, UXA, DRI, DRI2, GEM, KMS, etc.), and what > chips can use which features? Tino, Thanks for the question, and sorry for my late reply. In general, the release component info is maintained at http://intellinuxgraphics.org/download.html. So at that page you can find a recommended package (what we call 2008Q4 release, and it's -rc3 for now), with: xf86-video-intel: 2.6-branch. It's tagged as 2.5.99.2 for now. mesa: intel-2008-q4 branch. It's forked from master at some point (early Dec. 2008) and cherry-picked patches from master on demand, so a little more conservative than master. Of course master tip is supposed to work too, but not validated by Intel. libdrm: master branch. (note >2.4.2 is required for xf86-video-intel 2.6, and tip is recommended) kernel: Eric's drm-intel tree. For 2008Q4, we base on 2.6.28 kernel. So we are recommending drm-intel-2.6.28 branch, which adds 5 patches on top of 2.6.28. xserver: server-1.6-branch is recommended, though 1.5 should also work. For features, 2.5.99.1 adds some new features like HDMI audio, XvMC for Mpeg2 on i965. 2.5.99.2 are mostly bug fixes. Known issues are listed at http://intellinuxgraphics.org/community_testing.html These new features are all supported on i915 and later. We don't guarantee the stability on i8xx. You can test DRI2 by setting UXA in xorg.conf, then play with composite window manager. GEM is on if you use 2.6.28 kernel. KMS is not covered in this release package. It needs 2.6.29-ish kernel and not stable yet. Please let me know if any questions. Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching from X-Window to VT
John Tapsell wrote: > 2009/1/13 sdrb : >> John Tapsell wrote: >>> 2009/1/13 sdrb : Hi, I have a question regarding switching from X-Window to virtual terminal. Usually I use both of them and I very often switch between of them. The switching process usually takes 3-8 seconds (X11 -> VT). I have Intel E8400 processor and GF7600GT and I wonder why does the switching from X11 to VT take so much time, while switching in opposite direction is done almost immediately. The switching time even grows when I have firefox running with many of tabs. Could anyone explain what's going on? >>> Because xorg has drivers for setting up the video card, and so does >>> the kernel. So switching to a VT requires un-setting up the video card >>> by Xorg, then setting up the video card by the kernel. >>> >>> You'll be happy to know, however, that this will hopefully soon(ish) >>> be fixed. The idea is to move all of this to the kernel. >>> The first steps have already been done ( 2.6.28 kernel, out on >>> christmas day, came with GEM - >>> >>> http://kernelnewbies.org/Linux_2_6_28#head-b957b19f6139b6bbbfabaf790bf643b1746985d6 >>> ) >> Yes, I heard about GEM, but I'm very interested in what cause this effect. >> Is it possible to read more details (even low-level details) about this >> problem? > If you google for "kernel mode setting" you'll get dozens of hits. In > particular it's worth checking out the kerneltrap articles (those are > always good - http://kerneltrap.org/node/8242). Ok, thank you. sdrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Intel HDMI audio - No audio in X, works in console
Hi Bill,
On Mon, Jan 12, 2009 at 05:25:45PM +0200, Bill Wittig wrote:
> The xorg-server version is 1.5.3. I can't check specifically for the
> patch you referenced until tonight - perhaps you know if it's included
> in the released 1.5.3.
objdump -T /opt/X2/bin/Xorg | grep xf86MonitorIsHDMI
00494236 gDF .text 01c3 Base xf86MonitorIsHDMI
Can you see it for your Xorg? e.g.
objdump -T /usr/bin/Xorg | grep xf86MonitorIsHDMI
> I looked through the thread Sven referenced, and it looks like this is
> related to the ELD data, however, the end of that thread (as of 4 Jan)
> is that you can get working audio over HDMI or working video, but not
> both without completely disabling acceleration, so I'm hesitant to try
> that route.
Nod, that's a lot of trouble :)
Thanks,
Fengguang
> Quoting Wu Fengguang :
>
> > On Sun, Jan 11, 2009 at 07:03:18AM -0600, Bill Wittig wrote:
> >> Hi,
> >>
> >> I've got a G45 MB (Gigabyte EG45M-D2SH)
> >>
> >> I've installed the 2.5.99.2 xf86-video-intel driver
> >> the Realtek v5.09 ALSA modules which includes the ALSA v18a
> >> patch_intelhdmi code
> >>
> >> aplay -l shows the Intel HDMI device:
> >> List of PLAYBACK Hardware Devices
> >> card 0: Intel [HDA Intel], device 0: ALC883 Analog [ALC883 Analog]
> >>Subdevices: 1/1
> >>Subdevice #0: subdevice #0
> >> card 0: Intel [HDA Intel], device 1: ALC883 Digital [ALC883 Digital]
> >>Subdevices: 1/1
> >>Subdevice #0: subdevice #0
> >> card 0: Intel [HDA Intel], device 3: INTEL HDMI [INTEL HDMI]
> >>Subdevices: 1/1
> >>Subdevice #0: subdevice #0
> >>
> >> I'm using MythTV, audio output device set to ALSA:hw:0,3 (using 0,0
> >> works as expected for
> >> analog out)
> >>
> >> When MythTV is displayed (i.e. X is running), no sound is heard. If I
> >> switch to a console
> >> (Ctl-Alt-F1) the audio is working fine.
> >>
> >> Any ideas?
> >
> > Hi Bill,
> >
> > What's the xserver version? I'm asking this because it's not enough to
> > merely upgrade xf86-video-intel. The HDMI audio enabling code in which
> > depends on a recent feature of xserver.
> >
> > The exact logic works like this in xorg/xf86-video-intel/src/i830_hdmi.c:
> >
> > if (xf86LoaderCheckSymbol("xf86MonitorIsHDMI") &&
> > xf86MonitorIsHDMI(edid_mon))
> > dev_priv->has_hdmi_sink = TRUE;
> >
> >
> > if (dev_priv->has_hdmi_sink)
> > sdvox |= SDVO_AUDIO_ENABLE;
> >
> > So the xserver must have xf86MonitorIsHDMI() defined, which was introduced
> > in this xserver commit:
> >
> > commit 4cf2f4172abc4bf848c1726e6dac535713e08f0b
> > Author: Adam Jackson
> > Date: Mon Nov 3 12:50:28 2008 -0500
> >
> > Add xf86MonitorIsHDMI() helper.
> >
> >
> > Thanks,
> > Fengguang
> >
>
>
>
> --
> Bill Wittig
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: version > 6.9.0 does not work on Lenovo T400 when docked
please try radeonhd driver. On Tue, Jan 13, 2009 at 6:31 AM, Sascha Steinbiss wrote: > Hi everyone, > > I am unsure where to turn to in this matter, but it seems I have > encountered an issue in the current version of the xf86-video-ati module. > > I have a Lenovo T400 with a "ATI Technologies Inc Mobility Radeon HD > 3400 Series rev 0" graphics chip. Usually I boot up with the machine in > the dock, and use the DVI output there to drive a Samsung 24" display > (multi-head via xrandr). > > Version 6.9.0 works like a charm (though unaccelerated). However, using > any later version (tested with the 6.9.0.91 and 6.10.0 versions from the > Arch testing repository), when I boot up with the laptop docked all X > does is cycle through uniformly colored full screens on the internal > display (white->red->green->blue->grey->vertical black/white > gradient->horizontal black/white gradient), and the external DVI output > is ignored. The same happens when I boot up undocked, then put the > laptop in the dock and use xrandr to enable the DVI out. > > I attach my xorg.conf for debugging. Do you need any more information? > Should I file a bug in the bugzilla? Is this even the right place to > ask? If not, then I would be happy to get a pointer in the right direction. > > Thanks a lot in advance, > Sascha > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.5.99.2
On 2009.01.13 15:59:43 +0800, Tino Keitel wrote: > On Tue, Jan 13, 2009 at 08:59:06 +0800, Wang, Zhenyu Z wrote: > > [...] > > > Could you try 'intel-2008-q4' branch in mesa? > > No difference in glxgears. I didn't test googleearth and quake3 because > I don't want to reboot right now. > Forget to mention Eric's 'drm-2.6.28' stable branch on git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git, please test with libdrm git master too. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Switching from X-Window to VT
2009/1/13 sdrb : > John Tapsell wrote: >> >> 2009/1/13 sdrb : >>> >>> Hi, >>> >>> I have a question regarding switching from X-Window to virtual terminal. >>> Usually I use both of them and I very often switch between of them. >>> The switching process usually takes 3-8 seconds (X11 -> VT). >>> >>> I have Intel E8400 processor and GF7600GT and I wonder why does the >>> switching from X11 to VT take so much time, while switching in opposite >>> direction is done almost immediately. >>> The switching time even grows when I have firefox running with many of >>> tabs. >>> Could anyone explain what's going on? >> >> Because xorg has drivers for setting up the video card, and so does >> the kernel. So switching to a VT requires un-setting up the video card >> by Xorg, then setting up the video card by the kernel. >> >> You'll be happy to know, however, that this will hopefully soon(ish) >> be fixed. The idea is to move all of this to the kernel. >> The first steps have already been done ( 2.6.28 kernel, out on >> christmas day, came with GEM - >> >> http://kernelnewbies.org/Linux_2_6_28#head-b957b19f6139b6bbbfabaf790bf643b1746985d6 >> ) > > Yes, I heard about GEM, but I'm very interested in what cause this effect. > Is it possible to read more details (even low-level details) about this > problem? If you google for "kernel mode setting" you'll get dozens of hits. In particular it's worth checking out the kerneltrap articles (those are always good - http://kerneltrap.org/node/8242). > > Thank you rapid answer. > > sdrb > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Compositing, OpenGL programs and Intel graphics drivers
On Mon, 2009-01-12 at 17:34 -0800, Bipin George Mathew wrote: > > (1) What if I do not use DRI and explicitly use indirect rendering on > Intel. I tried exporting the LIBGL_ALWAYS_INDIRECT=1, but the initial > issue persisted. That's AIGLX, which also uses the DRI, so this is expected. > (2) When you say "Nvidia does not use the same infrastructure" - are > you referring to AIGLX? TTBOMK the nvidia driver doesn't use any of xserver's GLX/DRI/... infrastructure. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
