Re: problem with xset
On 05/17/2010 09:36 PM, Mike Oliver wrote: On 5/17/2010 9:15 PM, JD wrote: xset r rate 2 255 belches out the error that Xlib does not have XFree86-Misc for display 0:0 and my autorepeat gets set to 0 delay and probably maximum repeat rate, so that I am not even able to type any command. For example, doing an ls becomes: $ lss That sounds like it's working then. So instead of asking for a 2ms pause before the autorepeat begins and 255 repeats per second (which is what you're doing now), play with the numbers to get closer to the behaviour you really want. You said you wanted a slow repeat, right? Try 'xset r rate 1000 4', which should wait one second (1000ms) before beginning to repeat and should then repeat at a rate of 4 events per second. Mike. Thank you Mike, That did it. But the server still says: Xlib: extension XFree86-Misc missing on display :0.0. So why would the man page say the rate comes before the delay in the args list? What a *...@#$@%#$ man page!!! Even --help specifies the args backwards. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: C++/Shell Integration
Dirk Wallenstein hals...@t-online.de writes: On Sat, May 15, 2010 at 11:41:45PM +0100, Mubarak Aguye wrote: Hi. I was wondering if there is a way of determining the title of the current active window, and its x-y coordinates from within a C++ application, or even a standard Linux shell. For the shell, you could use 'xwininfo'. For C++, you would use XWindowAttributes and Properties. http://www.x.org/docs/X11/xlib.pdf (Chapter 3) http://tronche.com/gui/x/xlib/window-information/ And the currently active window, assuming you mean the window that is currently set up to receive key events from the primary keyboard, is probably the window you get from XGetInputFocus(). (If you mean something else by currently active window, you'll probably have to ask your window manager somehow.) eirik ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Opening a window without activating it
Andreas Falkenhahn andr...@airsoftsoftwair.de writes: Am Sunday 16 May 2010 schrieb Andreas Falkenhahn: I already checked out EWMH but I don't see any properties in that specification which could do what I want. read here: http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html set the InputHint to False, then map, then maybe set it to True (if you want to receive input focus by e.g. mouseclicks) Thanks, that does exactly what I want. That shouldn't be necessary, though. The only applications I know that takes focus when they start up are java applications. awt does an explicit XSetInputFocus() to itself when it creates a new window. So I think it is your window manager that is set up to automatically give focus to new windows (or as enlightenment 0.16 calls it: All new windows first get the focus) eirik ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (libXdmcp)
On Fri, May 7, 2010 at 7:40 AM, Chris Ball c...@laptop.org wrote: http://tinderbox.x.org/builds/2010-05-06-0019/logs/libXdmcp/#build AA32.c: In function 'XdmcpAllocARRAY32': AA32.c:47: error: 'UINT8_MAX' undeclared (first use in this function) AA8.c: In function 'XdmcpAllocARRAY8': AA8.c:47: error: 'UINT16_MAX' undeclared (first use in this function) please ignore this reply, testing something on the list with an issue. Dave. ___ %(real_name)s...@%(host_name)s: X.Org support Archives: http://lists.freedesktop.org/archives/%(list_name)s Info: %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s Your subscription address: %(user_address)
Re: Current tinderbox regression (libXdmcp)
On Tue, May 18, 2010 at 4:46 PM, Dave Airlie airl...@gmail.com wrote: On Fri, May 7, 2010 at 7:40 AM, Chris Ball c...@laptop.org wrote: http://tinderbox.x.org/builds/2010-05-06-0019/logs/libXdmcp/#build AA32.c: In function 'XdmcpAllocARRAY32': AA32.c:47: error: 'UINT8_MAX' undeclared (first use in this function) AA8.c: In function 'XdmcpAllocARRAY8': AA8.c:47: error: 'UINT16_MAX' undeclared (first use in this function) please ignore this reply, testing something on the list with an issue. Dave. and this one. Thanks Dave. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Current tinderbox regression (libXdmcp)
On Fri, May 7, 2010 at 7:40 AM, Chris Ball c...@laptop.org wrote: http://tinderbox.x.org/builds/2010-05-06-0019/logs/libXdmcp/#build AA32.c: In function 'XdmcpAllocARRAY32': AA32.c:47: error: 'UINT8_MAX' undeclared (first use in this function) AA8.c: In function 'XdmcpAllocARRAY8': AA8.c:47: error: 'UINT16_MAX' undeclared (first use in this function) http://cgit.freedesktop.org/xorg/lib/libXdmcp/commit/?id=30e388a8284ed100893983178acb6b4e3ff2b815 and really ignore this one. Dave. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: C++/Shell Integration
On Tue, May 18, 2010 at 08:06:45AM +0200, Eirik Byrkjeflot Anonsen wrote: Dirk Wallenstein hals...@t-online.de writes: On Sat, May 15, 2010 at 11:41:45PM +0100, Mubarak Aguye wrote: Hi. I was wondering if there is a way of determining the title of the current active window, and its x-y coordinates from within a C++ application, or even a standard Linux shell. For the shell, you could use 'xwininfo'. For C++, you would use XWindowAttributes and Properties. http://www.x.org/docs/X11/xlib.pdf (Chapter 3) http://tronche.com/gui/x/xlib/window-information/ And the currently active window, assuming you mean the window that is currently set up to receive key events from the primary keyboard, is probably the window you get from XGetInputFocus(). (If you mean something else by currently active window, you'll probably have to ask your window manager somehow.) yeah, X has different concepts of active windows. for the server, the active window is whichever one is underneath the pointer or the one that has the input focus (or one of the input foci with XI2). what users generally understand as active window is implemented by the window manager and may or may not be the same as the X server's window. You could have a WM that has a window activated and in the foreground although the input focus is still in some other window. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Current tinderbox regression (runtime, x11perf)
On Tue, May 18, 2010 at 2:35 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, May 17, 2010 at 11:01 PM, Chris Ball c...@laptop.org wrote:
Hi,
Have you updated the xserver and ddx as well? Do you know what
versions you were running when it last worked?
Yes -- git HEAD (of all xorg modules) as of Wed May 5 14:25:34 2010
EDT worked, and git HEAD as of three hours or so later crashed, and
git HEAD as of today crashes too.
This doesn't seem to match up precisely with any DDX or server
commits, which is curious. Do you have any r100 (or similarly old,
perhaps) hardware that you could try running x11perf on with git HEAD,
to see whether you share the hang?
The x11perf invocation I use is:
x11perf -repeat 3 -time 3
-{putimage,getimage,shmput,copy{win,pix}{win,pix}}{10,100,500} -noop
-{aa,rgb}{10,24,f}text -dot -rect{1,10,100,500}
The hang is 100% reproducible. I haven't tried reverting to check
that the hang disappears (to rule out e.g. a new hardware fault),
but that's probably a good sanity-check for me to do soon.
There haven't been any changes to the ddx in that timeframe that would
affect rn50. I'd say it's an xserver bug perhaps?
It could be, not sure of anything that has changed in rn50 recently,
it mostly should be doing sw rendering at the moment.
Dave.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Still a few doubts about Zaphod and Radeon
On Sat, May 15, 2010 at 12:36 PM, Lawrence Statton lawre...@cluon.com wrote: I feel that I have arrived at a fortuitous time in that Zaphod is (apparently) back I'm a greybeard and I *like* each of my monitors to have it's own X screen (:0.0, :0.1 and :0.2) for reasons that probably make sense to nobody but me. I have a IBM ThinkCentre with Intel 915 graphics on the motherboard and a Radeon 9000 series dual VGA PCI card. The motherboard video is driving a 22 HP LCD and the Radeon is driving a pair of HP 17 4:3 LCDs. After a side trip into my window manager sucks land, and me blaming the good folks over at GDM for compiz (and more importantly my own) lossage, I now have all three displays with distinct video in a usable but not quite perfect configuration. I'm up to two X screens, :0.0 ( the IGP video) and the radeon card driving a virtual 2560x1024 frame buffer driving the other two monitors. I saw Alex Deuchar's recent response on the list to Samud and I immediately tried to duplicate (as close as possible) their results, but without luck. Alex writes: You need to add Screen 0 and Screen 1 to your device sections Is this correct? When I tried to do this, I got a coredump Sorry to hijack this thread, someone has messed with list addresses. Dave. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Key continue repeating if setting global autorepeat off while the key was already repeating.
On Sun, Nov 22, 2009 at 08:27:47PM -0800, Octavio Alvarez wrote: If I turn global autorepeat off while a key is already being repeated, the key doesn't stop repeating. It continues on and on. At least according to XKB, I believe that's correct; almost all XKB actions are specified to not affect any keys currently down. Cheers, Daniel pgpgeYZIvmNvE.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
patch for xorg-xinput-fpit
Hi, i ran into a wired behavior with xorg-xinput-fpit. system compaq tc1000, ubuntu 10.04 seem that maxY ist assigned to maxX. see pastebin: http://pastebin.com/pZC3c16Q thanks, philip created a diff to correct the problem: diff --git a/src/xf86Fpit.c b/src/xf86Fpit.c index ce7540b..4c09c96 100644 --- a/src/xf86Fpit.c +++ b/src/xf86Fpit.c @@ -232,7 +232,7 @@ static void xf86FpitSetUpAxes(DeviceIntPtr dev, FpitPrivateP #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 axis_labels[0], #endif - priv-fpitMinY, priv-fpitMaxY, 9500, 0 / + priv-fpitMinX, priv-fpitMaxX, 9500, 0 / 9500 /* max_res */ ); InitValuatorAxisStruct(dev, 1, #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 -- ICQ# 609508529, IRC: phil...@chat.freenode.net ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Fullscreen windows - weird behaviour
Andreas Falkenhahn wrote: Andreas Falkenhahn wrote: Hi, I have the following setup: ... Anybody got a clue what's going on there? You could add test code that uses XQueryTree() to find out why. http://tronche.com/gui/x/xlib/window-information/XQueryTree.html Hmm, I'm not sure if this would help. What is really confusing me is the fact that even when I call XGrabPointer() on my main window (mode set to GrabModeAsync), I can still get the task bar to pop up. How can this happen? Isn't XGrabPointer() supposed to intercept delivery of all mouse events excepting the window specified in XGrabPointer()? When I call XGrabPointer() without changing the screen mode using XF86VidModeSwitchToMode() it works exactly like that: Everything on the desktop except my window seems frozen. Clicking on the taskbar doesn't trigger any action. It's completely dead. However, when calling XGrabPointer() after XF86VidModeSwitchToMode(), it's possible to pop the task bar to the front. It's pretty weird because I thought that after XGrabPointer() the mouse would be completely mine until I call XUngrabPointer(). Does XGrabPointer() return GrabSuccess? It won't if something else has grabbed it. http://tronche.com/gui/x/xlib/input/XGrabPointer.html ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: problem with xset
Op 18-05-10 08:11, JD schreef:
So why would the man page say the rate comes before the delay in the
args list?
What a *...@#$@%#$ man page!!!
As stated even if your very first post, in the manpage there is:
[-r [keycode]] [r [keycode]] [r {on|off}] [r rate _delay_ [_rate_]]
So it's correctly written delay, then rate. Admitely it's a bit
confusing to also have the rate keyword. That's the drawback of
reading manpages in English, it's much less confusing to read them in
French or Japanese ;-)
Eric
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: problem with xset
JD schrieb: On 05/17/2010 09:36 PM, Mike Oliver wrote: On 5/17/2010 9:15 PM, JD wrote: xset r rate 2 255 belches out the error that Xlib does not have XFree86-Misc for display 0:0 and my autorepeat gets set to 0 delay and probably maximum repeat rate, so that I am not even able to type any command. For example, doing an ls becomes: $ lss That sounds like it's working then. So instead of asking for a 2ms pause before the autorepeat begins and 255 repeats per second (which is what you're doing now), play with the numbers to get closer to the behaviour you really want. You said you wanted a slow repeat, right? Try 'xset r rate 1000 4', which should wait one second (1000ms) before beginning to repeat and should then repeat at a rate of 4 events per second. Mike. Thank you Mike, That did it. But the server still says: Xlib: extension XFree86-Misc missing on display :0.0. So why would the man page say the rate comes before the delay in the args list? What a *...@#$@%#$ man page!!! Even --help specifies the args backwards. my man page says: The first specifies the delay before autorepeat starts and the second specifies the repeat rate. is there an other line ? re, wh ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: ati radeon x2300 problem after upgrading ubuntu kernel
hi, thanks for the reply. here is what i found with the dmesg, cropped at loading the vga part. i do find that they are quite different, which is suspicious because the rest of the log is pretty much the same. however i still don't know what the problem is. rather interesting is this part (see the last line of each part, marked with ) (in kernel 2.6.32-15) = [ 29.988374] fb0: radeondrmfb frame buffer device [ 29.988377] registered panic notifier [ 29.988384] [drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0 [ 29.991893] vga16fb: initializing [ 29.991897] vga16fb: mapped to 0xc00a [ 29.992059] fb1: VGA16 VGA frame buffer device = (in kernel 2.6.32-22) = [ 31.677043] fb0: radeondrmfb frame buffer device [ 31.677046] registered panic notifier [ 31.677052] [drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0 [ 31.757850] vga16fb: initializing [ 31.757855] vga16fb: mapped to 0xc00a [ 31.757859] vga16fb: not registering due to another framebuffer present = this is the most contrast part from other things. i don't understand what it means, but it seems something is not working in kernel 2.6.32-22, while it works in the previous kernel 2.6.32-15 although the starting procedure is exactly the same. for full reference (at least what i understand to be the correct part): cropped dmesg of kernel 2.6.32-15 == [ 29.242349] [drm] radeon defaulting to kernel modesetting. [ 29.242352] [drm] radeon kernel modesetting enabled. [ 29.242436] radeon :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 29.242449] radeon :01:00.0: setting latency timer to 64 [ 29.244630] [drm] radeon: Initializing kernel modesetting. [ 29.244665] [drm] register mmio base: 0xFDFF [ 29.244667] [drm] register mmio size: 65536 [ 29.244816] ATOM BIOS: Asus [ 29.245045] [drm] GPU reset succeed (RBBM_STATUS=0x1140) [ 29.245069] [drm] Generation 2 PCI interface, using max accessible memory [ 29.245073] [drm] radeon: VRAM 128M [ 29.245075] [drm] radeon: VRAM from 0x to 0x07FF [ 29.245077] [drm] radeon: GTT 512M [ 29.245079] [drm] radeon: GTT from 0x2000 to 0x3FFF [ 29.245190] alloc irq_desc for 29 on node -1 [ 29.245193] alloc kstat_irqs on node -1 [ 29.245219] radeon :01:00.0: irq 29 for MSI/MSI-X [ 29.245278] [drm] radeon: irq initialized. [ 29.246051] [drm] Detected VRAM RAM=128M, BAR=256M [ 29.246056] [drm] RAM width 64bits DDR [ 29.248799] [TTM] Zone kernel: Available graphics memory: 436822 kiB. [ 29.248803] [TTM] Zone highmem: Available graphics memory: 1030586 kiB. [ 29.248825] [drm] radeon: 128M of VRAM memory ready [ 29.248827] [drm] radeon: 512M of GTT memory ready. [ 29.248850] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 29.251815] [drm] RB2D reset succeed (RBBM_STATUS=0x1140) [ 29.251863] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 29.261639] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 29.261665] [drm] radeon: cp idle (0x1C03) [ 29.261773] [drm] Loading R500 Microcode [ 29.262047] platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin [ 29.310343] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 29.310967] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use [ 29.310971] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or [ 29.310974] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. [ 29.336309] [drm] radeon: ring at 0x2000 [ 29.336356] [drm] ring test succeeded in 3 usecs [ 29.336543] [drm] radeon: ib pool ready. [ 29.337070] [drm] ib test succeeded in 0 usecs [ 29.337325] [drm] Radeon Display Connectors [ 29.337327] [drm] Connector 0: [ 29.337329] [drm] VGA [ 29.337332] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 29.337334] [drm] Encoders: [ 29.337336] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 29.337338] [drm] Connector 1: [ 29.337340] [drm] LVDS [ 29.337343] [drm] DDC: 0x7e30 0x7e30 0x7e34 0x7e34 0x7e38 0x7e38 0x7e3c 0x7e3c [ 29.337345] [drm] Encoders: [ 29.337347] [drm] LCD1: INTERNAL_LVTM1 [ 29.337359] [drm] Connector 2: [ 29.337360] [drm] S-video [ 29.337362] [drm] Encoders: [ 29.337363] [drm] TV1: INTERNAL_KLDSCP_DAC2 [ 29.337365] [drm] Connector 3: [ 29.337367] [drm] DVI-I [ 29.337370] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 29.337372] [drm] Encoders: [ 29.337374] [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [ 29.464641] alloc kstat_irqs on node -1 [ 29.464650] HDA Intel :00:1b.0: PCI INT A - GSI 21 (level, low) - IRQ 21 [ 29.464695] HDA Intel :00:1b.0: setting latency timer to 64 [ 29.466182] phy0: Selected rate control algorithm 'iwl-3945-rs' [ 29.670321] type=1505
Re: patch for xorg-xinput-fpit
On Tue, May 18, 2010 at 09:43:36AM +0200, Philip wrote: Hi, i ran into a wired behavior with xorg-xinput-fpit. system compaq tc1000, ubuntu 10.04 seem that maxY ist assigned to maxX. see pastebin: http://pastebin.com/pZC3c16Q thanks, philip created a diff to correct the problem: diff --git a/src/xf86Fpit.c b/src/xf86Fpit.c index ce7540b..4c09c96 100644 --- a/src/xf86Fpit.c +++ b/src/xf86Fpit.c @@ -232,7 +232,7 @@ static void xf86FpitSetUpAxes(DeviceIntPtr dev, FpitPrivateP #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 axis_labels[0], #endif - priv-fpitMinY, priv-fpitMaxY, 9500, 0 / + priv-fpitMinX, priv-fpitMaxX, 9500, 0 / 9500 /* max_res */ ); InitValuatorAxisStruct(dev, 1, #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 7 thanks, looks good. Please have a look at http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches though and re-send this as a patch generated by git-format patch (signed off). I'll push it asap then. Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
commit 'dri2: Send out event when auxillary buffers are invalidated' breaks nouveau 3D support
Hi, It could be my mistake, but I have uptodate versions of xproto, dri2proto, xserver, nouveau ddx, mesa, libdrm. Still the above commit makes X not load nouveau dri module, and fallback to swrast_dri.so. Nothing in X logs, but that 'Screen is not AIGLX capable' Best regards, Maxim Levitsky ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: LCD picture quality 2.6.27 vs 2.6.33
On Sun, 2010-05-16 at 14:07 -0700, SD wrote: Dear All. During many month I was trying to figure out what is wrong with picture on my Fedora 13. I have laptop with i915GM video and two OS on it - OpenSuse 11.1 and Fedora 13. Suse shows picture perfect, but Fedora does not. I use XFCE on both OS. Both OS is updated. I took digital picture of my screen, and would like you all to analyze it. Left side Fedora, right side is OpenSuse. Both OS has: Subpixel: horizontal rgb, according to xrandr --verbose If you have a good and a bad OS, one useful comparison might be to gather the output from this command on both: sudo intel_reg_dumper You may need intel_gpu_tools installed for this. Hazarding a guess (and sorry, that is about all I can do to help you), is that the panel timings might be being detected incorrectly on Fedora. The programming differences should show up in the register dumps. I've no idea what different kernel versions / patches / 2D driver versions are used in the distro versions mentioned. Make sure you're testing with compiz / visual effects disabled, to rule out a 3D issue - but from the looks of the picture, I'm sceptical that is the problem. 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!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: commit 'dri2: Send out event when auxillary buffers are invalidated' breaks nouveau 3D support
On Tue, 2010-05-18 at 14:13 +0300, Maxim Levitsky wrote: Hi, It could be my mistake, but I have uptodate versions of xproto, dri2proto, xserver, nouveau ddx, mesa, libdrm. Still the above commit makes X not load nouveau dri module, and fallback to swrast_dri.so. Nothing in X logs, but that 'Screen is not AIGLX capable' Never mind that, it was due to stale headers after all.. Sorry for noise. Best regards, Maxim Levitsky ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: patch for xorg-xinput-fpit
On Tue, 18 May 2010 21:10:00 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: thanks, looks good. Please have a look at http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches though and re-send this as a patch generated by git-format patch (signed off). I'll push it asap then. Cheers, Peter Thanks Peter, i will do my best... -- Philip feu...@uni-koblenz.de ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Fullscreen windows - weird behaviour
On 18.05.2010 at 19:29 Russell Shaw wrote: Andreas Falkenhahn wrote: Andreas Falkenhahn wrote: Hi, I have the following setup: ... Anybody got a clue what's going on there? You could add test code that uses XQueryTree() to find out why. http://tronche.com/gui/x/xlib/window-information/XQueryTree.html Hmm, I'm not sure if this would help. What is really confusing me is the fact that even when I call XGrabPointer() on my main window (mode set to GrabModeAsync), I can still get the task bar to pop up. How can this happen? Isn't XGrabPointer() supposed to intercept delivery of all mouse events excepting the window specified in XGrabPointer()? When I call XGrabPointer() without changing the screen mode using XF86VidModeSwitchToMode() it works exactly like that: Everything on the desktop except my window seems frozen. Clicking on the taskbar doesn't trigger any action. It's completely dead. However, when calling XGrabPointer() after XF86VidModeSwitchToMode(), it's possible to pop the task bar to the front. It's pretty weird because I thought that after XGrabPointer() the mouse would be completely mine until I call XUngrabPointer(). Does XGrabPointer() return GrabSuccess? It won't if something else has grabbed it. Yes, I checked this of course. It returns 0 every time. Well, maybe it's a bug in openSUSE 11.2/kde4 because it works alright on Ubuntu and Fedora. I can't really make sense of the behaviour in openSUSE because the pointer should really be mine. It's weird. Greets, Andreas -- Remember: It's nice to be important but it's more important to be nice! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-mga 1.4.12
Adam Jackson (1): mga 1.4.12 Alan Coopersmith (1): Update Sun license notices to current X.Org standard form Gaetan Nadon (6): .gitignore: use common defaults with custom section # 24239 Several driver modules do not have a ChangeLog target in Makefile.am #23814 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES configure.ac: use backticks rather than $() for cmd subs Yannick Heneault (4): updated G200eW PLL programming sequence. Removed DDC1 support for G200eW. Added support for G200EH Changed probe_size value to detect up to 16Megs of video ram on G200eV. git tag: xf86-video-mga-1.4.12 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mga-1.4.12.tar.bz2 MD5: 2b6390753ce4d97e2623ce43f8abf22a xf86-video-mga-1.4.12.tar.bz2 SHA1: ff84e9035a375dde76d789f5bbc4efbbca8a33fc xf86-video-mga-1.4.12.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-mga-1.4.12.tar.gz MD5: ae9954ba5a8d8421db66115ff6040044 xf86-video-mga-1.4.12.tar.gz SHA1: 81b1e95e3881c754691879a50b239e3516e2011b xf86-video-mga-1.4.12.tar.gz - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Current tinderbox regression (runtime, x11perf)
Hi, The hang is 100% reproducible. I haven't tried reverting to check that the hang disappears (to rule out e.g. a new hardware fault), but that's probably a good sanity-check for me to do soon. I got a serial port hooked up to the machine. Here's the last thing we see on the kernel console and in the Xorg log: [drm:radeon_fence_wait] *ERROR* fence(df3689b0:0xA1A5) 552ms timeout [drm:radeon_fence_wait] *ERROR* last signaled fence(0xA1A5) [drm:radeon_fence_wait] *ERROR* fence(df368d70:0xA1AE) 505ms timeout going to reset GPU [drm] RB2D reset succeed (RBBM_STATUS=0x8007C100) [drm] CP reset succeed (RBBM_STATUS=0x8006C100) [drm] radeon: cp idle (0x8080) [drm] radeon: ring at 0xC000 [drm] ring test succeeded in 2 usecs [drm] GPU reset succeed (RBBM_STATUS=0x0140) [drm:radeon_fence_wait] *ERROR* fence(df368d70:0xA1AE) 556ms timeout [drm:radeon_fence_wait] *ERROR* last signaled fence(0xA1AE) [drm:radeon_fence_wait] *ERROR* fence(df368730:0xBD1E) 516ms timeout [drm:radeon_fence_wait] *ERROR* last signaled fence(0xBD1E) [drm:radeon_fence_wait] *ERROR* fence(df3689b0:0xBD24) 506ms timeout going to reset GPU [drm] RB2D reset succeed (RBBM_STATUS=0x8007C100) [drm] CP reset succeed (RBBM_STATUS=0x8002C100) [drm] radeon: cp idle (0x8080) radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. [drm] radeon: ring at 0xC000 machine hung - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
