xcompmgr -- Bugfix: missing determine_mode() in configure_win()
Hello,
it appears configure_win() lacks a call to determine_mode() so
window mode is uninitialised in subsequent call to win_extents().
Greetings,
Eeri Kask
--- xcompmgr.c.DetermineMode.orig 2009-09-25 15:18:10.0 +0200
+++ xcompmgr.c 2009-09-25 15:18:56.0 +0200
@@ -1568,6 +1568,7 @@
restack_win (dpy, w, ce-above);
if (damage)
{
+ determine_mode (dpy, w);
XserverRegion extents = win_extents (dpy, w);
XFixesUnionRegion (dpy, damage, damage, extents);
XFixesDestroyRegion (dpy, extents);
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Dual keyboards no longer work properly in latest X
On Thu, 2009-09-24 at 14:04 -0700, David Wake wrote: This is driving me nuts because I am used to using two separate keyboards, one for each hand. Does anyone have any ideas on how to debug or fix this? Even a clue as to how to debug X's handling of modifier keys would be very welcome! I've seen this in 1.6.x but not in 1.7.x. I tried to chase it down in 1.6 but ran screaming away. - ajax 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: xcompmgr -- Proposal 2: ARGB-window dropoff shadow
Le vendredi 25 septembre 2009 à 11:02 -0400, Joel Feiner a écrit : On 09/25/2009 09:54 AM, Yann Droneaud wrote: Le mercredi 23 septembre 2009 à 21:10 +0200, Eeri Kask a écrit : Hello, it appears xcompmgr does not decorate windows with ARGB 32-bit visuals; which at first sight seems probably a preference of artistic taste than a result of engineering considerations. :-) If client window want to be transparent, putting a rectangular shadow around / under it is not a desired feature (ex: cairo-clock). The same apply to XShape'd window (ex: xeyes). IMHO, shadows should optional and a window should be able to ask for none through a property. Regards. Why not fix the shadow under window issue and then this won't be a problem? XShape windows, of course, should still have no shadows (unless the shadows can be shaped to the window, but that seems like it would be hard to achieve). Creating rectangular shadows is a bad things for windows with non-rectangular content. And creating a shadow that match the content shape is not trivial (at least for me :): you should take care of hole in the window content (think of a donut for example: is there a full shadow in the center, or only on the border ?) I'm OK for the rectangular shadow by default for all windows only if there's a EWMH property to disable it, but there's currently none AFAIK. Regards. -- Yann Droneaud ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xcompmgr -- Proposal 2: ARGB-window dropoff shadow
Le vendredi 25 septembre 2009 à 17:23 +0200, Yann Droneaud a écrit : Creating rectangular shadows is a bad things for windows with non-rectangular content. And creating a shadow that match the content shape is not trivial (at least for me :): you should take care of hole in the window content (think of a donut for example: is there a full shadow in the center, or only on the border ?) I'm wrong regarding xcompmgr's shadows. The way they're made, they are better than, for example, KDE's ones. See following examples: xcompmgr without shadow: https://quoi.quest-ce.net/data/xcompmgr/xcompmgr.jpeg xcompmgr with shadow: https://quoi.quest-ce.net/data/xcompmgr/xcompmgr-s.jpeg kwin with shadow: https://quoi.quest-ce.net/data/xcompmgr/kwin.jpeg PS: something is disturbing here ... my test window use an ARGB32 visual and is decorated with xcompmgr's shadow. So what's the purpose of the initial proposal. Did i miss another thing ? Regards. -- Yann Droneaud ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Writing a xorg driver for OTI-64111, looking for documentation on OTI-088
On Tue, 2009-09-22 at 15:12 -0500, Alex Villacís Lasso wrote: After a lot of googling, I found a PDF file of a photocopy of a datasheet for the OAK 64107 graphics chipset, which seems very similar to the 64111 that I have. With this, the OAK.TXT file from the VGADOC zipfile floating around the net, and examination of register settings on the card itself, I have managed to write a basic driver that can switch into 8-bit, 16-bit, 24-bit and 32-bit modes without help from the VESA BIOS. The supported resolutions are up to 832x624 pixels. Now, I know that the chipset can do at least 1024x768 non-interlaced, because I remember seeing this resolution back when the target machine ran Windows 95 (it now runs updated Fedora 10). However, I still don't know how to set the supposed higher pixel clock speeds required for 1024x768 and beyond. The 64107 datasheet says the clock chip is an OTI-088, so I am looking for documentation on this chip. Does any of you have this datasheet? I have tried the Wayback site but to no avail. I have an actual paper book [1] describing a bunch of Oak chips, including the 64107. But I don't see anything obviously describing the high-res modes on the 64105/64107. There _is_ a mode table that ends with: ModeResolution Colors -- ... 5fh 640 by 480 24 60h 800 by 600 16 61h 640 by 400 8 h 640 by 480 32 h 800 by 600 32 h 1024 by 768 32 and no, the missing numbers are not typos, that's how it actually ends. I'd guess they're 0x62 through 0x64? [1] Programmer's Guide to the EGA, VGA, and Super VGA Cards, Third Edition. Richard F. Ferraro, Addison-Wesley. - ajax 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: exa/nouveau segfault
running xserver git by any chance? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
Hi, Sorry for the delay. Here it is the backtrace. (gdb) bt #0 0x7f1a24e3cae3 in NV50EXACheckTexture (ppict=0x1767a20, pdpict=0x164e4c0, op=3) at nv50_exa.c:482 #1 0x7f1a24e3cc4a in NV50EXACheckComposite (op=3, pspict=0x1767a20, pmpict=0x1767b10, pdpict=0x164e4c0) at nv50_exa.c:739 #2 0x7f1a2338802c in exaTryDriverComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:679 #3 0x7f1a23388d94 in exaComposite (op=3 '\003', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:1019 #4 0x004def7d in damageComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=value optimized out, xDst=value optimized out, yDst=value optimized out, width=value optimized out, height=value optimized out) at damage.c:643 #5 0x004d1aae in ProcRenderComposite (client=0x846d70) at render.c:723 #6 0x004371e4 in Dispatch () at dispatch.c:445 #7 0x004247ea in main (argc=19, argv=0x7fff0c6a0958, envp=value optimized out) at main.c:285 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x7f1a26978f25 in raise () from /lib/libc.so.6 (gdb) bt #0 0x7f1a26978f25 in raise () from /lib/libc.so.6 #1 0x7f1a2697a2c0 in abort () from /lib/libc.so.6 #2 0x0047dc12 in ddxGiveUp () at xf86Init.c:1212 #3 0x00479102 in FatalError (f=0x59f110 Caught signal %d (%s). Server aborting\n) at log.c:404 #4 0x00475d9d in OsSigHandler (signo=11, sip=0xc, unused=value optimized out) at osinit.c:156 #5 signal handler called #6 0x7f1a24e3cae3 in NV50EXACheckTexture (ppict=0x1767a20, pdpict=0x164e4c0, op=3) at nv50_exa.c:482 #7 0x7f1a24e3cc4a in NV50EXACheckComposite (op=3, pspict=0x1767a20, pmpict=0x1767b10, pdpict=0x164e4c0) at nv50_exa.c:739 #8 0x7f1a2338802c in exaTryDriverComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:679 #9 0x7f1a23388d94 in exaComposite (op=3 '\003', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:1019 #10 0x004def7d in damageComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=value optimized out, xDst=value optimized out, yDst=value optimized out, width=value optimized out, height=value optimized out) at damage.c:643 #11 0x004d1aae in ProcRenderComposite (client=0x846d70) at render.c:723 #12 0x004371e4 in Dispatch () at dispatch.c:445 #13 0x004247ea in main (argc=19, argv=0x7fff0c6a0958, envp=value optimized out) at main.c:285 Appreciate your help, Sebastian - Original Message From: Maarten Maathuis madman2...@gmail.com To: Sebastian Glita gls...@yahoo.com Cc: xorg@lists.freedesktop.org Sent: Monday, September 14, 2009 3:00:01 PM Subject: Re: exa/nouveau segfault On Mon, Sep 14, 2009 at 12:27 PM, Sebastian Glita gls...@yahoo.com wrote: Hello, I use xorg-server/xf86-video-nouveau/nouveau-drm/mesa/libdrmet.al. from git.freedesktop.org. [A 2-3 days update solved the trouble with console switching, always restarting Xorg/gdm. Great relief.] Since 1-2 weeks ago I keep getting this segfault whenever launching windows except x11vnc/xterm/mplayer. Also using gtk+/glib from git.gnome.org. A proper backtrace made with gdb would help, some debug symbols would be useful too, at least for nouveau. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xcompmgr -- Bugfix: missing determine_mode() in configure_win()
it appears configure_win() lacks a call to determine_mode() so window mode is uninitialised in subsequent call to win_extents(). Attached is an alternative, probably a better solution to that above problem: introduce the missing determine_mode() into add_win() as this problem affects clients started _after_ starting xcompmgr, and which therefore are not yet 'mapped', but will be 'configured' first. Greetings, Eeri Kask --- xcompmgr.c.AddWinDetermineMode.orig 2009-09-25 18:08:07.0 +0200 +++ xcompmgr.c 2009-09-25 18:07:34.0 +0200 @@ -1479,6 +1479,8 @@ *p = new; if (new-a.map_state == IsViewable) map_win (dpy, id, new-damage_sequence - 1, True); +else + determine_mode (dpy, new); } static void ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xcompmgr -- Proposal 2: ARGB-window dropoff shadow
Am 09/25/2009 03:54 PM, Yann Droneaud schrieb: Le mercredi 23 septembre 2009 à 21:10 +0200, Eeri Kask a écrit : Hello, it appears xcompmgr does not decorate windows with ARGB 32-bit visuals; which at first sight seems probably a preference of artistic taste than a result of engineering considerations. :-) If client window want to be transparent, putting a rectangular shadow around / under it is not a desired feature (ex: cairo-clock). The same apply to XShape'd window (ex: xeyes). IMHO, shadows should optional and a window should be able to ask for none through a property. Regards. As it looks like there really seem no apparent _technical_ restrictions involved to not draw a drop-off shadow around transparent or heavily XShaped client windows? Then, how to proceed in the case of conflict of interests if, as opposed to some particular client window, the computer user still prefers a shadow even around semitransparent or XShaped windows (i.e. beyond the rectangular area (in the sense of the X-window attribute) enclosing the window and its border)? :-) Apart from the fact that semitransparent (and XShaped) windows in general need not have a nonrectangular outer shape at all, therefore as long as there is no property-based mechanism for client-based shadow on-off configuration yet, and in fact even unrelated to that, it looks quite reasonable to let the computer user resolve this above conflict (by some xyz command line parameter), don't you agree? :-) (Of course let's keep xcompmgr's default behaviour to not draw shadows around ARGB windows but introduce a method to override this default.) Greetings, Eeri Kask ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
On Fri, Sep 25, 2009 at 8:35 PM, Sebastian Glita gls...@yahoo.com wrote: Yes, patch URIs accepted. tx. S. - Original Message From: Maarten Maathuis madman2...@gmail.com To: Sebastian Glita gls...@yahoo.com Cc: xorg@lists.freedesktop.org Sent: Friday, September 25, 2009 8:12:55 PM Subject: Re: exa/nouveau segfault running xserver git by any chance? Maarten. Could you retry latest xf86-video-nouveau git? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
Yes, patch URIs accepted. tx. S. - Original Message From: Maarten Maathuis madman2...@gmail.com To: Sebastian Glita gls...@yahoo.com Cc: xorg@lists.freedesktop.org Sent: Friday, September 25, 2009 8:12:55 PM Subject: Re: exa/nouveau segfault running xserver git by any chance? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
