Re: xkbmap with combining diacritics
On 02/18/2013 12:52 PM, Simos Xenitellis wrote:
On Mon, Feb 18, 2013 at 10:25 PM, Joshua Crowgeyjcrow...@uw.edu wrote:
Hi xorg,
It was recommended to me in #xorg on irc that I should post this question to
your list. I hope this is appropriate.
I have been attempting to define a keyboard mapping for typing Lushootseed
(aka, Puget Salish) [iso639-3:lut]. Ideally, I will use the layout that
Dave Sienko at Tulalip has already implemented in Tauvlesoft.
http://www.tulaliplushootseed.com/NWIC-103-2009/Lushootseed%20Font%20%20Keyboard.htm
To do so, I created a lut.symbols file which handles much of the job
(attached). Here's a snippet:
keyAD01 { [ q, Q, U0251, U252 ] };
keyAD02 { [ w, W, U01BF, U01F7 ] };
keyAD03 { [ schwa, E, schwa, SCHWA] };
keyAD04 { [ U0161, R,U0279, U027E ] };
However, I was unable to implement the mapping (shown in the link to
tulaliplushootseed.com) completely because the output of many of the upper
case (shifted) keystrokes should be a series of unicode characters rather
than a single one. That is, I have to use combining diacritics. However, I
was unable to define a series of characters in this file without generating
an error. For example, each of the following attempts fail because, from
what I can tell, there's no way to include more than a single unicode
code-point as one of the values in the array. I haven't discovered any
quoting or grouping mechanism.
---
keyAD01 { [ q, q̓, U0251, U252 ] };
---
---
keyAD01 { [ q, q̓, U0251, U252 ] };
---
---
keyAD01 { [ q, qU0313, U0251, U252 ] };
---
---
keyAD01 { [ q, U0071U0313, U0251, U252 ] };
---
---
keyAD01 { [ q, U0071+U0313,U0251, U252 ] };
---
The question is this: is there a way to define keyboards that implement
characters that include combining diacritics in the output of specific keys?
Where can I find out more about what steps I should undertake to define an
official keyboard for typing Lushootseed on xorg?
Please let me know if this question is more appropriate for another list or
if I should refine the question in some way.
Hello,
For your requirements and the complexity of the keyboard layout, you
may have a better chance to create a keyboard layout for iBus. See
more at http://code.google.com/p/ibus/
It is possible to create a keyboard layout with XKB, however I think
it will be more complicated than necessary.
If you are happy to make something quick and dirty, you can create the
necessary compose sequences and put them in ~/.Xcompose
Simos
Hello Simos,
Thank you for the suggestions. In fact, I did get something working by
creating an .XCompose file (should it be .Xcompose with lower c?). And
at one point, I even got that working. I had to set some environment
variables such as GTK_IM_MODULE=xim and I think I had to run imswitch
and set it to SCIM? In any case, I went away for a week and haven't
gotten that approach working again. It would be nice if there was a
setxcompose command that let me dynamically set the xcompose file or
not. When typing in English, for example, I don't want the XCompose
file to be active. I want it active after switching to Lushootseed.
I also played around with ibus but it seems to be a bit tricky to get
working on debian testing at the moment. My package manager is chocking
on an ibus dependency of im-clutter, which seems to have some sort of
error as of the last time I tried to install it.
In short, I appreciate the reply and I'll try renaming my ~/.XCompose to
~/.Xcompose to see if that makes a difference with automatically finding it.
Best regards,
--Joshua
PS: here is my XCompose file as I have authored it:
jcrowgey@citrus:~$ cat ~/.XCompose
Q : q̓
W : w̓
E : q̓ʷ
R :
T : t̕
Y : y̓
U :
I : kʷ
O :
P : p̓
A : qʷ
S :
D : dᶻ
F :
G : gʷ
H :
J : k̓ʷ
K : k̓
L : l̕
colon : ƛ̕
z : x̌
Z : x̌ʷ
X : xʷ
C : c̓
V : č̓
B :
N : n̓
M : m̓
The one time I got this working, I ran 'setxkbmap lut' to set the keys
that didn't require combining diacritics.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Nominations for X.Org Foundation Board of Directors are OPEN (resend)
(I sent this to announce, xorg and xorg-devel lists but forgot the members list. To account for this mistake, the nomination window is being extended to March 10. The email below is the same as previously, with the dates adjusted.) We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2012 election are now open and will remain open until 23.59 GMT on 10 March 2013. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2011 were Matthias Hopf, Keith Packard, Matt Dew, and Alex Deucher. They will continue to serve until their term ends in 2013. Current directors whose term expires in 2012 are Eric Anholt, Alan Coopersmith, Stuart Kreitman, and Bart Massey. A director is expected to participate in the bi-weekly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23.59 GMT on 10 March 2013. The slate of candidates will be published 11 March 2013 and candidate QA will begin then. The deadline for Xorg membership applications and renewals is 15 March 2011. The Election Committee X.Org Foundation ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Initial DRI3000 protocol specs available
On Wed, Feb 20, 2013 at 10:17:56PM -0800, Keith Packard wrote: Chris Wilson ch...@chris-wilson.co.uk writes: You manage ask yourself the question I was trying to lead: how the heck does the compositor learn that the underlying graphics object has changed? It can certainly tell that the underlying contents have changed with Damage events, but as to how it knows that it should do another BufferFromPixmap request, I think that's gonna require another event. Now, the big question is how to deal with compositing managers which don't know about DRI3. I suspect we'll just have to skip the DMA-BUF swapping hack for window pixmaps unless the compositor gives us the OK to do so. If a DRI2 client also grabs the buffer, then we have to fallback to blits. That should be fairly easy to detect and handle. In DRI2 this is through the InvalidateEvent, and the lack of being able to send those from the driver before the Damage is sent is one of the reasons why the current exchange mechanism is broken. Hrm. With the current system, except for override-redirect windows, if the compositor is also the window manager, it should always know when the window pixmap is going to be replaced because that only happens when the window is resized, and the window manager is entirely responsible for making that happen. For override-redirect windows, if the ConfigureNotify event was delivered before the Damage event, then the compositor could know about that as well. We are concerned with the GEM objects backing the Pixmaps, which may be changed at whim by the driver. I guess I'd like to know more about what is broken with the current system for compositors... We cannot perform simple name exchanges currently in DRI2 because the Damage is badly ordered wrt the Invalidate event and there is no coordination between client - server - compositor on when the buffers are reusable by the client. In any case, as the underlying DMA-BUF is changing, the compositor is going to need to know that so it can release the old pixmap back to the application, and so it can rewire its own compositing operations to use the new object. It might be nice to have the compositor use persistent names for the various DMA-BUFs that are used for a particular window. I think that means having the compositor hold on to old DMA-BUF window pixmap IDs. That seems tricky though. The alternative will be to have the compositor create/destroy a pixmap ID per frame. Not intolerable, but not optimal. Getting buffer exchanges working in conjunction with the external compositor is more or less as tricky as it gets. The notion that the buffer is kept busy by the compositor and so prevents the DRI3 client from overdrawing it is key. And that naturally leads to the compositor needing to release the old buffer once it is referencing the new post-swap buffer. Right, an easy technique there would be to have it use NameWindowPixmap when it got an event telling it that a new pixmap was in use for the window, and then when it was finished with that pixmap, it could just use FreePixmap to tell the server it was done. That would bump the refcnt down to one in the server, at which point it could queue the pixmap to be sent as 'idle' the next time SwapRegion was called. Serialisation between rendering of the common buffers is definitely s.e.p. I agree that should solve the compositor problem. Ok, cool. So, changes that I think are needed: 1) If someone calls TextureFromPixmap on a window pixmap, we need to suppress the window pixmap swapping hack. Alternatively, we can have the compositor explicitly enable window pixmap swapping. I think we definitely want to support window swapping with DRI3 compositors. DRI2 compositors will just have to continue to force blits. 2) We need to send an event when the buffer underlying a window switches. 3) We need to be explicit about event ordering between the new window pixmap change notify event and any related Damage. As I see it the challenge is to prevent sending the buffer release (SwapIdle) back to the client before all interested third parties have had a chance to snoop its contents and react. Sketching that out we need to increment the busy count everytime we send an Invalidate and expect the client (compositor) to send a release after they have finished processing the buffer. For fun, imagine a fullscreen redirected Window (because Wine still manages to confuse everybody): client servercompositor new drawable - setup Damage show A (Swap) - invalidate buffer damage - - show A (Swap) flip A show B invalidate buffer damage - - show B
Re: Initial DRI3000 protocol specs available
On 21 February 2013 07:17, Keith Packard kei...@keithp.com wrote: Chris Wilson ch...@chris-wilson.co.uk writes: Hrm. With the current system, except for override-redirect windows, if the compositor is also the window manager, it should always know when There are compositors that are not window mangers I use one because without a compositor xwd -id does not work. Thanks Michal ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Initial DRI3000 protocol specs available
Hi, And for Render, along with passing blobs. Yeah, I can easily imagine doing a PictureFromBuffer as well. Let's focus on Pixmaps for now and get Mesa fixed up. Passing blobs (if this means what I think it does) would be something we are looking forward for Java's XRender backend. Currently we upload 32x32 alpha masks using XPutImage and most drivers (except SNA/intel) don't cope with this very well. In effect it would help to cure the weakness of XRender when it comes to geometry. Regards, Clemens ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] os: use libunwind to generate backtraces
21 lut 2013 00:37, Peter Hutterer peter.hutte...@who-t.net napisał(a):
On Tue, Feb 19, 2013 at 09:29:03PM +0100, Marcin Slusarz wrote:
[...]
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] os: use libunwind to generate backtraces
Libunwind generates backtraces much more reliably than glibc's
backtrace.
Before:
0: /opt/xserver/bin/X (0x40+0x18ce36) [0x58ce36]
1: /opt/xserver/bin/X (xorg_backtrace+0x9) [0x58d119]
2: /opt/xserver/bin/X (0x40+0x190d69) [0x590d69]
3: /lib64/libpthread.so.0 (0x7fb904268000+0x10a90) [0x7fb904278a90]
4: /lib64/libc.so.6 (ioctl+0x7) [0x7fb902fbf987]
5: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fb90405ffa8]
6: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fb90406235b]
7: /usr/lib64/libdrm_nouveau.so.2 (nouveau_bo_wait+0x89)
[0x7fb902009719]
8: /opt/xserver/lib/xorg/modules/drivers/nouveau_drv.so
(0x7fb90220e000+0x76f3) [0x7fb9022156f3]
9: /opt/xserver/lib/xorg/modules/libexa.so (0x7fb9019c7000+0xbae0)
[0x7fb9019d2ae0]
10: /opt/xserver/bin/X (0x40+0x17d2b3) [0x57d2b3]
11: /opt/xserver/bin/X (0x40+0xc9930) [0x4c9930]
12: /opt/xserver/bin/X (0x40+0x3a81a) [0x43a81a]
13: /opt/xserver/bin/X (0x40+0x3d6a1) [0x43d6a1]
14: /opt/xserver/bin/X (0x40+0x2c2ca) [0x42c2ca]
15: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fb902f019b5]
16: /opt/xserver/bin/X (0x40+0x2c60d) [0x42c60d]
17: ?? [0x0]
After:
0: /opt/xserver/bin/X (OsSigHandler+0x39) [0x590d69]
1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fb904278a8f]
2: /lib64/libc.so.6 (ioctl+0x7) [0x7fb902fbf987]
3: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fb90405ffa8]
4: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fb90406235b]
5: /usr/lib64/libdrm_nouveau.so.2 (nouveau_bo_wait+0x89)
[0x7fb902009719]
6: /opt/xserver/lib/xorg/modules/drivers/nouveau_drv.so
(nouveau_exa_download_from_screen+0x1a3) [0x7fb9022156f3]
7: /opt/xserver/lib/xorg/modules/libexa.so (exaGetImage+0x1f0)
[0x7fb9019d2ae0]
8: /opt/xserver/bin/X (miSpriteGetImage+0x173) [0x57d2b3]
9: /opt/xserver/bin/X (compGetImage+0xb0) [0x4c9930]
10: /opt/xserver/bin/X (ProcGetImage+0x55a) [0x43a81a]
11: /opt/xserver/bin/X (Dispatch+0x341) [0x43d6a1]
12: /opt/xserver/bin/X (main+0x3ba) [0x42c2ca]
13: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fb902f019b5]
14: /opt/xserver/bin/X (_start+0x29) [0x42c60d]
15: ? (?+0x29) [0x29]
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
configure.ac| 7 +
include/dix-config.h.in | 3 ++
os/Makefile.am | 5
os/backtrace.c | 75
+
4 files changed, 90 insertions(+)
diff --git a/configure.ac b/configure.ac
index 9415a54..4a292da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -309,6 +309,13 @@ AC_CHECK_HEADER([execinfo.h],[
])]
)
+PKG_CHECK_MODULES(LIBUNWIND, libunwind, [HAVE_LIBUNWIND=yes],
[HAVE_LIBUNWIND=no])
+if test x$HAVE_LIBUNWIND = xyes; then
+ AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
+fi
+AM_CONDITIONAL(HAVE_LIBUNWIND, [test x$HAVE_LIBUNWIND = xyes])
+
+
dnl
---
dnl Bus options and CPU capabilities. Replaces logic in
dnl hw/xfree86/os-support/bus/Makefile.am, among others.
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 578f249..5102263 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -60,6 +60,9 @@
/* Has backtrace support */
#undef HAVE_BACKTRACE
+/* Has libunwind support */
+#undef HAVE_LIBUNWIND
+
/* Define to 1 if you have the byteswap.h header file. */
#undef HAVE_BYTESWAP_H
diff --git a/os/Makefile.am b/os/Makefile.am
index 8891485..364b6da 100644
--- a/os/Makefile.am
+++ b/os/Makefile.am
@@ -34,6 +34,11 @@ if XDMCP
libos_la_SOURCES += $(XDMCP_SRCS)
endif
+if HAVE_LIBUNWIND
+AM_CFLAGS += $(LIBUNWIND_CFLAGS)
+libos_la_LIBADD += $(LIBUNWIND_LIBS)
+endif
+
EXTRA_DIST = $(SECURERPC_SRCS) $(XDMCP_SRCS)
if SPECIAL_DTRACE_OBJECTS
diff --git a/os/backtrace.c b/os/backtrace.c
index daac60c..426f9b1 100644
--- a/os/backtrace.c
+++ b/os/backtrace.c
@@ -30,6 +30,80 @@
#include errno.h
#include string.h
+#ifdef HAVE_LIBUNWIND
+
+#define UNW_LOCAL_ONLY
+#include libunwind.h
+
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+#include dlfcn.h
+
+void
+xorg_backtrace(void)
+{
+unw_cursor_t cursor;
+unw_context_t context;
+unw_word_t off;
+unw_proc_info_t pip;
+int ret, i = 0;
+char procname[256];
+const char *filename;
+Dl_info dlinfo;
+
+pip.unwind_info = NULL;
+ret = unw_getcontext(context);
+if (ret) {
+ErrorFSigSafe(unw_getcontext failed: %s [%d]\n,
unw_strerror(ret),
+ret);
+return;
+}
+
Re: Patch for compose key sequences J with acute
On 2013-02-20 17:28, James Cloos wrote: One quick review note: Per 10646 and unicode, that miniscule sequence should be U+006A U+0301 j́ and not U+0237 U+0303 ȷ́. Do you mean (only fix in tyop in quote of my proposal): U+006A U+0301 j́ and not U+0237 U+0301 ȷ́. I just noticed that on bitmap fonts such as the command line, one still sees the dot of the j or a j followed by a filled diamond shape. The i and j are defined to have soft dots; all combining sequence starting with either MUST ignore the dot on the base character. Not all font/rendering engines tuples get this right, but they should, and searches et al probably expect j́. So indeed there is some work on the rendering part. Attached is a new patch with you improvement. Does anyone would like to have the reverse order supported and/or dead keys supported for this? -JimC Regards, Pander diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index de24dad..6c4dc6f 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -618,6 +618,7 @@ XCOMM Part 3 Multi_key I quotedbl : à Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS Multi_key diaeresis I : à Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS Multi_key I diaeresis : à Idiaeresis # LATIN CAPITAL LETTER I WITH DIAERESIS +Multi_key J acute : JÌ# LATIN CAPITAL LETTER J U004A with COMBINING ACUTE ACCENT U0301 Multi_key D H : à ETH # LATIN CAPITAL LETTER ETH dead_tilde N : à Ntilde # LATIN CAPITAL LETTER N WITH TILDE Multi_key asciitilde N : à Ntilde # LATIN CAPITAL LETTER N WITH TILDE @@ -738,6 +739,7 @@ XCOMM Part 3 Multi_key i quotedbl : ï idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS Multi_key diaeresis i : ï idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS Multi_key i diaeresis : ï idiaeresis # LATIN SMALL LETTER I WITH DIAERESIS +Multi_key j acute : jÌ# LATIN SMALL LETTER J U006A with COMBINING ACUTE ACCENT U0301 Multi_key d h : ð eth # LATIN SMALL LETTER ETH dead_tilde n : ñ ntilde # LATIN SMALL LETTER N WITH TILDE Multi_key asciitilde n : ñ ntilde # LATIN SMALL LETTER N WITH TILDE ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Initial DRI3000 protocol specs available
Stéphane Marchesin stephane.marche...@gmail.com writes: With that said, I don't think it's that difficult/different. I can design a GLX extension spec and send a draft, then we can work from there. Yeah, some concrete plan for GL would be really nice to have, at least as a starting point. That is actually not what you want because it is a waste of bandwidth. Since compositors are typically bandwidth limited, you instead want to paint only the relevant sub regions. Those are easy to determine by transforming X damage regions into screen coordinates. Of course, that's what SwapRegion is for -- it will get to pick whether to copy or page flip and let the client know what happened, the region you pass Most non-trivial compositing managers are already using partial update schemes through GLX_MESA_copy_sub_buffer or the GLX_EXT_buffer_age extensions + copies. I don't think it is far fetched to support a list of rectangles instead. A region is already a list of rectangles; the only restriction that the relative location of all of the source and dest rectangles is the same. This satisfies the goal of doing a damage-based back-front update. -- keith.pack...@intel.com pgpb3Q267E6v2.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] parser: handle negative numbers properly
Numbers beginning with '-' were falling into the DASH category.
This also caused a confusing error message, since no terminating NUL
character was added to configRBuf -- old garbage in the string would be
printed. This fixes the terminating NUL for COMMA as well.
Signed-off-by: Robert Morell rmor...@nvidia.com
---
hw/xfree86/parser/scan.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index f852b83..b74d21b 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/scan.c
@@ -338,18 +338,26 @@ xf86getToken(xf86ConfigSymTabRec * tab)
/* GJA -- handle '-' and ',' * Be careful: -hsync is a keyword. */
else if ((c == ',') !isalpha(configBuf[configPos])) {
+configRBuf[i] = '\0';
return COMMA;
}
-else if ((c == '-') !isalpha(configBuf[configPos])) {
+else if ((c == '-') !isalnum(configBuf[configPos])) {
+configRBuf[i] = '\0';
return DASH;
}
/*
* Numbers are returned immediately ...
*/
-if (isdigit(c)) {
+if (isdigit(c) || (c == '-' isdigit(configBuf[configPos]))) {
int base;
+i = 0;
+if (c == '-') {
+configRBuf[i++] = c;
+c = configBuf[configPos++];
+}
+
if (c == '0')
if ((configBuf[configPos] == 'x') ||
(configBuf[configPos] == 'X')) {
@@ -365,8 +373,7 @@ xf86getToken(xf86ConfigSymTabRec * tab)
val.numType = PARSE_DECIMAL;
}
-configRBuf[0] = c;
-i = 1;
+configRBuf[i++] = c;
while (isdigit(c = configBuf[configPos++]) ||
(c == '.') || (c == 'x') || (c == 'X') ||
((base == 16) (((c = 'a') (c = 'f')) ||
@@ -374,7 +381,7 @@ xf86getToken(xf86ConfigSymTabRec * tab)
configRBuf[i++] = c;
configPos--;/* GJA -- one too far */
configRBuf[i] = '\0';
-val.num = strtoul(configRBuf, NULL, 0);
+val.num = strtol(configRBuf, NULL, 0);
val.realnum = atof(configRBuf);
return NUMBER;
}
--
1.7.12.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Initial DRI3000 protocol specs available
Chris Wilson ch...@chris-wilson.co.uk writes: If a DRI2 client also grabs the buffer, then we have to fallback to blits. That should be fairly easy to detect and handle. So, the question is whether the NameWindowPixmap IDs are stable across pixmap replacement. I'm frankly tempted to add a new event to Composite that is sent whenever the window pixmap changes -- that way applications wouldn't have to guess that the pixmap changed whenever the window was resized. This would also provide an opportunity to improve resize performance as the X server could over-allocate window pixmaps during the resize operation, and then shrink them back down once the final size had been selected. We are concerned with the GEM objects backing the Pixmaps, which may be changed at whim by the driver. Huh? We cannot perform simple name exchanges currently in DRI2 because the Damage is badly ordered wrt the Invalidate event and there is no coordination between client - server - compositor on when the buffers are reusable by the client. Right, so we clearly need to pass the backing buffer from application to X server and thence to the compositor. What I'm not sure about is how to name these buffers, and how to scope their lifetime. Here's a quick proposal -- have the X server assign server XIDs to the buffers, and send those XIDs to the compositor in events. Now the compositor is responsible for telling the server (some new 'IdlePixmap' call?) when it finishes with the objects, at which point they can be released back to the application. We'd need some magic to make sure the pixmaps got freed if the compositor crashed, but I think that's easier than trying to figure out how to allocate XIDs in the compositor ID space from within the X server. This would replace NameWindowPixmap, and would eliminate the current race conditions between the ConfigureNotify and the NameWindowPixmap call while also providing traceable ownership of the buffer contents: busyapplication X servercompositor A Draw to buffer A Allocate pixmap ID for buffer A, 'Pixmap Aa' SwapRegion Pixmap Aa Allocate server ID for Pixmap Aa, 'Pixmap Ax' Send 'window pixmap changed' event 'Pixmap Ax' Receive event Convert 'Pixmap Ax' into buffer A using TextureFromPixmap paint screen using buffer A ... AB Draw to buffer B Allocate pixmap ID for buffer B, 'Pixmap Ba' SwapRegion Pixmap Ba Allocate server id for Pixmap Ba, 'Pixmap Bx' Send 'window pixmap changed' event 'Pixmap Ax' Receive event IdlePixmap Pixmap Ax Convert 'Pixmap Bx' into buffer B using TextureFromPixmap paint screen using buffer B B Mark Pixmap Aa as idle BC Draw to buffer C Allocate pixmap ID for buffer C, 'Pixmap Ca' SwapRegion Pixmap Ca Reply with Pixmap Aa idle Allocate server id for Pixmap Ca, 'Pixmap Cx' Send 'window pixmap changed' event 'Pixmap Cx' Receive event IdlePixmap Pixmap Bx Convert 'Pixmap Cx' into buffer C using TextureFromPixmap paint screen using buffer C C Mark Pixmap Ba as idle CA Draw to buffer A SwapRegion Pixmap Aa Reply with Pixmap Ba idle Send 'window pixmap changed' event 'Pixmap Ax' Receive event IdlePixmap Pixmap Cx paint screen using buffer A A Mark Pixmap Ca as idle At this point, we're in a steady state, using three buffers for the window -- a 'back buffer', a 'front buffer' and an 'idle buffer'. One easy thing for memory usage is to consider idle buffers as suitable for discard in the kernel; that would get us to one pinned buffer in the idle case, although we'd be using three buffers while active. It would be nice to flip between two buffers instead, but there may be compositor rendering traffic in flight using buffer A as the application draws to B and then C. Hrm. What we need is for the client to learn that the compositor has marked a buffer idle before it starts drawing; the current design places that information in the reply to SwapRegion,
Nominations for X.Org Foundation Board of Directors are OPEN (resend)
(I sent this to announce, xorg and xorg-devel lists but forgot the members list. To account for this mistake, the nomination window is being extended to March 10. The email below is the same as previously, with the dates adjusted.) We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2012 election are now open and will remain open until 23.59 GMT on 10 March 2013. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2011 were Matthias Hopf, Keith Packard, Matt Dew, and Alex Deucher. They will continue to serve until their term ends in 2013. Current directors whose term expires in 2012 are Eric Anholt, Alan Coopersmith, Stuart Kreitman, and Bart Massey. A director is expected to participate in the bi-weekly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23.59 GMT on 10 March 2013. The slate of candidates will be published 11 March 2013 and candidate QA will begin then. The deadline for Xorg membership applications and renewals is 15 March 2011. The Election Committee X.Org Foundation ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] os: use libunwind to generate backtraces
On Thu, Feb 21, 2013 at 08:00:07AM +0100, Marcin Ślusarz wrote:
21 lut 2013 00:37, Peter Hutterer peter.hutte...@who-t.net napisał(a):
On Tue, Feb 19, 2013 at 09:29:03PM +0100, Marcin Slusarz wrote:
[...]
---
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [PATCH] os: use libunwind to generate backtraces
Libunwind generates backtraces much more reliably than glibc's
backtrace.
Before:
0: /opt/xserver/bin/X (0x40+0x18ce36) [0x58ce36]
1: /opt/xserver/bin/X (xorg_backtrace+0x9) [0x58d119]
2: /opt/xserver/bin/X (0x40+0x190d69) [0x590d69]
3: /lib64/libpthread.so.0 (0x7fb904268000+0x10a90) [0x7fb904278a90]
4: /lib64/libc.so.6 (ioctl+0x7) [0x7fb902fbf987]
5: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fb90405ffa8]
6: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fb90406235b]
7: /usr/lib64/libdrm_nouveau.so.2 (nouveau_bo_wait+0x89)
[0x7fb902009719]
8: /opt/xserver/lib/xorg/modules/drivers/nouveau_drv.so
(0x7fb90220e000+0x76f3) [0x7fb9022156f3]
9: /opt/xserver/lib/xorg/modules/libexa.so (0x7fb9019c7000+0xbae0)
[0x7fb9019d2ae0]
10: /opt/xserver/bin/X (0x40+0x17d2b3) [0x57d2b3]
11: /opt/xserver/bin/X (0x40+0xc9930) [0x4c9930]
12: /opt/xserver/bin/X (0x40+0x3a81a) [0x43a81a]
13: /opt/xserver/bin/X (0x40+0x3d6a1) [0x43d6a1]
14: /opt/xserver/bin/X (0x40+0x2c2ca) [0x42c2ca]
15: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fb902f019b5]
16: /opt/xserver/bin/X (0x40+0x2c60d) [0x42c60d]
17: ?? [0x0]
After:
0: /opt/xserver/bin/X (OsSigHandler+0x39) [0x590d69]
1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7fb904278a8f]
2: /lib64/libc.so.6 (ioctl+0x7) [0x7fb902fbf987]
3: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fb90405ffa8]
4: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x7fb90406235b]
5: /usr/lib64/libdrm_nouveau.so.2 (nouveau_bo_wait+0x89)
[0x7fb902009719]
6: /opt/xserver/lib/xorg/modules/drivers/nouveau_drv.so
(nouveau_exa_download_from_screen+0x1a3) [0x7fb9022156f3]
7: /opt/xserver/lib/xorg/modules/libexa.so (exaGetImage+0x1f0)
[0x7fb9019d2ae0]
8: /opt/xserver/bin/X (miSpriteGetImage+0x173) [0x57d2b3]
9: /opt/xserver/bin/X (compGetImage+0xb0) [0x4c9930]
10: /opt/xserver/bin/X (ProcGetImage+0x55a) [0x43a81a]
11: /opt/xserver/bin/X (Dispatch+0x341) [0x43d6a1]
12: /opt/xserver/bin/X (main+0x3ba) [0x42c2ca]
13: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fb902f019b5]
14: /opt/xserver/bin/X (_start+0x29) [0x42c60d]
15: ? (?+0x29) [0x29]
Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
---
configure.ac| 7 +
include/dix-config.h.in | 3 ++
os/Makefile.am | 5
os/backtrace.c | 75
+
4 files changed, 90 insertions(+)
diff --git a/configure.ac b/configure.ac
index 9415a54..4a292da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -309,6 +309,13 @@ AC_CHECK_HEADER([execinfo.h],[
])]
)
+PKG_CHECK_MODULES(LIBUNWIND, libunwind, [HAVE_LIBUNWIND=yes],
[HAVE_LIBUNWIND=no])
+if test x$HAVE_LIBUNWIND = xyes; then
+ AC_DEFINE(HAVE_LIBUNWIND, 1, [Have libunwind support])
+fi
+AM_CONDITIONAL(HAVE_LIBUNWIND, [test x$HAVE_LIBUNWIND = xyes])
+
+
dnl
---
dnl Bus options and CPU capabilities. Replaces logic in
dnl hw/xfree86/os-support/bus/Makefile.am, among others.
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index 578f249..5102263 100644
--- a/include/dix-config.h.in
+++ b/include/dix-config.h.in
@@ -60,6 +60,9 @@
/* Has backtrace support */
#undef HAVE_BACKTRACE
+/* Has libunwind support */
+#undef HAVE_LIBUNWIND
+
/* Define to 1 if you have the byteswap.h header file. */
#undef HAVE_BYTESWAP_H
diff --git a/os/Makefile.am b/os/Makefile.am
index 8891485..364b6da 100644
--- a/os/Makefile.am
+++ b/os/Makefile.am
@@ -34,6 +34,11 @@ if XDMCP
libos_la_SOURCES += $(XDMCP_SRCS)
endif
+if HAVE_LIBUNWIND
+AM_CFLAGS += $(LIBUNWIND_CFLAGS)
+libos_la_LIBADD += $(LIBUNWIND_LIBS)
+endif
+
EXTRA_DIST = $(SECURERPC_SRCS) $(XDMCP_SRCS)
if SPECIAL_DTRACE_OBJECTS
diff --git a/os/backtrace.c b/os/backtrace.c
index daac60c..426f9b1 100644
--- a/os/backtrace.c
+++ b/os/backtrace.c
@@ -30,6 +30,80 @@
#include errno.h
#include string.h
+#ifdef HAVE_LIBUNWIND
+
+#define UNW_LOCAL_ONLY
+#include libunwind.h
+
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE
+#endif
+#include dlfcn.h
+
+void
+xorg_backtrace(void)
+{
+unw_cursor_t cursor;
+unw_context_t context;
+unw_word_t off;
+unw_proc_info_t pip;
+int ret, i = 0;
+char procname[256];
+const char *filename;
+Dl_info dlinfo;
+
+
Nominations for X.Org Foundation Board of Directors are OPEN (resend)
(I sent this to announce, xorg and xorg-devel lists but forgot the members list. To account for this mistake, the nomination window is being extended to March 10. The email below is the same as previously, with the dates adjusted.) We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2012 election are now open and will remain open until 23.59 GMT on 10 March 2013. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2011 were Matthias Hopf, Keith Packard, Matt Dew, and Alex Deucher. They will continue to serve until their term ends in 2013. Current directors whose term expires in 2012 are Eric Anholt, Alan Coopersmith, Stuart Kreitman, and Bart Massey. A director is expected to participate in the bi-weekly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the members account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23.59 GMT on 10 March 2013. The slate of candidates will be published 11 March 2013 and candidate QA will begin then. The deadline for Xorg membership applications and renewals is 15 March 2011. The Election Committee X.Org Foundation ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
[Bug 28106] radeon KMS causes hardware conflict/interference with Intel wifi and audio, crashes wireless
https://bugs.freedesktop.org/show_bug.cgi?id=28106 --- Comment #74 from Vassil Panayotov vd.panayo...@gmail.com --- Just for the record I've tried Kubuntu 12.04.02 and the kwin_gles workaround does _not_ work for me unfortunately(T60 w/ X1400) . There are still messages like CE: hpet increased min_delta_ns to 20113 nsec, and the wireless is very slow. This issue is very frustrating and is the first time when the open source model fails to work for me. I mean this report was filed 3 years ago, affects thousands of people, there is no good workaround and yet no one from the radeon developers seems to care. I wonder if we can raise money and put together a bounty or something... (posted this on https://bugs.launchpad.net/bugs/879790 24 hours ago but for some reason it's not synchronized yet, so posting it here manually too) -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 28106] radeon KMS causes hardware conflict/interference with Intel wifi and audio, crashes wireless
https://bugs.freedesktop.org/show_bug.cgi?id=28106 Vassil Panayotov vd.panayo...@gmail.com changed: What|Removed |Added CC||vd.panayo...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
