Re: I18n text input
Glynn Clements wrote: Russell Shaw wrote: For functions XkbLookupKeySym(), XLookupString(), XKeycodeToKeysym(), XKeysymToString etc, how can i tell if the keysym is a graphic printable character like a, or a control character such as Left (XK_Left) ? I need to tell automatically if it's a normal unicode character that can be printed in an entry box for any written language. For languages other than English, keyboard input isn't as simple as one keypress = one character. Many Western languages use dead accents (i.e. pressing an accent key causes the next character to be accented) or compose processing (e.g. Compose,o,/ = ø), and East-Asian languages typically require far more complex input methods. Do these functions return UTF-8 unicode? XLookupString() uses ISO-8859-1. XmbLookupString() and XwcLookupString() return strings in a locale-specific encoding. If X_HAVE_UTF8_STRING is defined, Xutf8LookupString() returns a UTF-8 string. Hi, I vaguely remember seeing Xutf8LookupString() years ago. All three functions require an input context (see XOpenIM() and XCreateIC() for a starting point, but you probably aren't going to work it out from manual pages alone). Unless you're planning on spending the next few months learning how text entry works for languages other than English, I'd recommend using a GUI toolkit rather than trying to do it using bare Xlib. Or at least steal the code from such a toolkit. I understand everything about non-english text entry and processing. When i do: XIM im = XOpenIM(app-display, NULL, NULL, NULL); im is set to a valid XIM rather than NULL. I thought an input method was supposed to be a separate process, but i haven't started one or used one previously. Where is this one coming from? What sort of text entry can i do with it? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exaGetPixmapFirstPixel Question
On Tue, 2010-01-19 at 13:42 +0900, Soo Chan Lim wrote:
Hi.
I am trying to make a ddx exa video driver at my owned target.
When I test the driver, I have met some error from Xserver.
The error log is bleow,
=
Fatal server error:
exaGetPixmapFirstPixel called for invalid bpp 1
=
And backtrace at the exaGetPixmapFirstPixel function is below
==
Breakpoint 1, exaGetPixmapFirstPixel (pPixmap=0x477618)
at ../../exa/exa_unaccel.c:507
507 switch (pPixmap-drawable.bitsPerPixel) {
(gdb) bt
#0 exaGetPixmapFirstPixel (pPixmap=0x477618)
at ../../exa/exa_unaccel.c:507
#1 0x406529c0 in exaTryDriverSolidFill (pSrc=0x488ec0,
pDst=0x488ce0,
xSrc=0, ySrc=0, xDst=5, yDst=10, width=1, height=127)
at ../../exa/exa_render.c:300
#2 0x40654c88 in exaComposite (op=1 '\001', pSrc=0x488ec0,
pMask=0x0,
pDst=0x488ce0, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=5, yDst=10,
width=1, height=127) at ../../exa/exa_render.c:923
#3 0x0014ccc4 in damageComposite (op=1 '\001', pSrc=0x488ec0,
pMask=0x0,
pDst=0x488ce0, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=5, yDst=10,
width=1, height=127) at ../../../miext/damage/damage.c:643
#4 0x0013392c in CompositePicture (op=1 '\001', pSrc=0x488ec0,
pMask=0x0,
pDst=0x488ce0, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=5, yDst=10,
width=1, height=127) at ../../render/picture.c:1718
#5 0x0013b24c in ProcRenderComposite (client=0x433898)
at ../../render/render.c:723
#6 0x00140324 in ProcRenderDispatch (client=0x433898)
at ../../render/render.c:2056
#7 0x00024650 in Dispatch () at ../../dix/dispatch.c:445
#8 0x00022414 in main (argc=11, argv=0xbec9bd04, envp=0xbec9bd34)
at ../../dix/main.c:285
(gdb) p pPixmap-drawable.bitsPerPixel
$1 = 1 '\001'
=
At exaGetPixmapFirstPixel, the xserver calls the FatalError when the
bpp of the pixmap is 1.
I have two questions at this point.
1. Is this exa module bug? I mean the xserver has the bug?
Yeah, exaGetPixmapFirstPixel() and/or its caller probably needs to be
fixed to handle this.
--
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
Re: I18n text input
Russell Shaw wrote: Unless you're planning on spending the next few months learning how text entry works for languages other than English, I'd recommend using a GUI toolkit rather than trying to do it using bare Xlib. Or at least steal the code from such a toolkit. I understand everything about non-english text entry and processing. When i do: XIM im = XOpenIM(app-display, NULL, NULL, NULL); im is set to a valid XIM rather than NULL. I thought an input method was supposed to be a separate process, but i haven't started one or used one previously. Where is this one coming from? What sort of text entry can i do with it? Simpler input methods (dead keys and compose) are built into X. More complex methods (e.g. those for CJK) use a separate IM server. If your locale is for a Latin-based language, you should be able to use dead keys and compose processing. For a UK keyboard, AltGr and the rightmost keys (=[]#'/) normally act as dead keys, while Shift-AltGr is Compose. There is more information on the API in §13.5 of the Xlib manual. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Different cursor _themes_ for multiple pointers?
On Fri, 15 Jan 2010 09:31:58 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, Jan 14, 2010 at 11:20:16PM +0100, Antonio Ospite wrote: Hi, inspired by a previous discussion[1] I've written a dumb tool to control cursors for multiple pointers with Xcursor and XInput2: http://git.ao2.it/xicursorset.git/?a=blob;f=xicursorset.c;hb=HEAD Now I have a question, would it be possible to change the whole cursor theme for an arbitrary pointer in a multi-pointer setup? last I checked, cursors are simply XIDs that are assigned to a device. all the theme handling is done on the client side, isn't it? That means it's WM (or toolkit, or application) responsibility to change cursor shape to indicate some state change, right? so you might have to shuffle around a bit switching cursor themes before loading but there's no server-side support necessary for this. Of course, you could extend the Xcursor spec and API to hold multiple cursor themes simultaneously, which may be the right thing to do long-term. I guess, so clients can know which theme is globally assigned to each pointer. I was thinking naively to something like: XcursorBool \ XIcursorSetTheme(Display *dpy, int deviceid, const char *theme); char *XIcursorGetTheme(Display *dpy, int deviceid); I don't know it that fits into XInput2 (like XIDefineCursor) or in Xcursor itself, and anyways I need to learn a lot about X before making any serious proposal. Cheers, Peter Slightly OT: I've written a blog post to roughly summarize the current state of multi-pointer support on a (GNOME) Desktop, it's more targeted at users, but developers might take some hints too: http://ao2.it/en/blog/2010/01/19/poor-mans-multi-touch-using-multiple-mice-xorg Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpjUDemLfawP.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libpciaccess x86 backend
Hi,
I put some minor comments bellow. Make sure you send your future patches to
xorg-de...@lists.freedesktop.org instead.
On Sun, Jan 17, 2010 at 06:30:00PM +0100, ext Samuel Thibault wrote:
This adds support on x86 for OSes that do not have a PCI interface,
tinkering with I/O ports, and makes use of it on GNU/Hurd.
diff --git a/configure.ac b/configure.ac
index ffc1c8d..535d704 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,6 +90,9 @@ case $host_os in
solaris=yes
PCIACCESS_LIBS=$PCIACCESS_LIBS -ldevinfo
;;
+ gnu*)
+ gnu=yes
+ ;;
esac
AM_CONDITIONAL(LINUX, [test x$linux = xyes])
@@ -97,6 +100,7 @@ AM_CONDITIONAL(FREEBSD, [test x$freebsd = xyes])
AM_CONDITIONAL(NETBSD, [test x$netbsd = xyes])
AM_CONDITIONAL(OPENBSD, [test x$openbsd = xyes])
AM_CONDITIONAL(SOLARIS, [test x$solaris = xyes])
+AM_CONDITIONAL(GNU, [test x$gnu = xyes])
AC_SYS_LARGEFILE
diff --git a/src/Makefile.am b/src/Makefile.am
index 4c06c25..8afd53b 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -51,6 +51,10 @@ else
VGA_ARBITER = common_vgaarb_stub.c
endif
+if GNU
+OS_SUPPORT = x86_pci.c
+endif
change the name for gnuhurd_pci.c makes more sense for me, given all file
there now are OS related.
libpciaccess_la_SOURCES = common_bridge.c \
common_iterator.c \
common_init.c \
diff --git a/src/common_init.c b/src/common_init.c
index 6b9b936..89c56ad 100644
--- a/src/common_init.c
+++ b/src/common_init.c
@@ -62,6 +62,8 @@ pci_system_init( void )
err = pci_system_openbsd_create();
#elif defined(__sun)
err = pci_system_solx_devfs_create();
+#elif defined(__GNU__)
+err = pci_system_x86_create();
I think the same name idea applies for all functions. So I'd prefer something
like pci_system_gnuhurd_create(), etc.
#endif
return err;
diff --git a/src/pciaccess_private.h b/src/pciaccess_private.h
index 77eb57b..ef0 100644
--- a/src/pciaccess_private.h
+++ b/src/pciaccess_private.h
@@ -167,4 +167,5 @@ extern int pci_system_netbsd_create( void );
extern int pci_system_openbsd_create( void );
extern void pci_system_openbsd_init_dev_mem( int );
extern int pci_system_solx_devfs_create( void );
+extern int pci_system_x86_create( void );
extern void pci_io_cleanup( void );
diff --git a/src/x86_pci.c b/src/x86_pci.c
new file mode 100644
index 000..b5725ef
--- /dev/null
+++ b/src/x86_pci.c
@@ -0,0 +1,669 @@
+/*
+ * Copyright (c) 2009 Samuel Thibault
+ * Heavily inspired from the freebsd, netbsd, and openbsd backends
+ * (C) Copyright Eric Anholt 2006
+ * (C) Copyright IBM Corporation 2006
+ * Copyright (c) 2008 Juan Romero Pardines
+ * Copyright (c) 2008 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#define _GNU_SOURCE
+#include unistd.h
+#include stdio.h
+#include stdlib.h
+#include errno.h
+#include fcntl.h
+#include sys/mman.h
+#include string.h
+#include strings.h
+
+#include pciaccess.h
+#include pciaccess_private.h
+
+#if defined(__GNU__)
+
+#include sys/io.h
+
+static int
+x86_enable_io(void)
+{
+if (!ioperm(0, 0x, 1))
+return 0;
+return errno;
+}
+
+static int
+x86_disable_io(void)
+{
+if (!ioperm(0, 0x, 0))
+return 0;
+return errno;
+}
+
+#elif defined(__GLIBC__)
+
+#include sys/io.h
I'd put hearders on the top...
+
+static int
+x86_enable_io(void)
+{
+if (!iopl(3))
+return 0;
+return errno;
+}
+
+static int
+x86_disable_io(void)
+{
+if (!iopl(0))
+return 0;
+return errno;
+}
+
+#else
+
+#error How to enable IO ports on this system?
+
+#endif
+
+#define PCI_VENDOR(reg)((reg) 0x)
+#define PCI_VENDOR_INVALID 0x
+
+#define PCI_VENDOR_ID 0x00
+#define PCI_SUB_VENDOR_ID 0x2c
+#define PCI_VENDOR_ID_COMPAQ 0x0e11
+#define PCI_VENDOR_ID_INTEL0x8086
+
+#define PCI_DEVICE(reg)(((reg) 16) 0x)
+#define PCI_DEVICE_INVALID 0x
+
+#define PCI_CLASS 0x08
+#define PCI_CLASS_DEVICE 0x0a
+#define PCI_CLASS_DISPLAY_VGA 0x0300
+#define PCI_CLASS_BRIDGE_HOST
Xorg crash with input device plug/unplug
Originally filed at: https://bugzilla.redhat.com/show_bug.cgi?id=550948 I use an usb-switch device to switch keyboard+mouse between machines. This has worked fine for 4+ years. But in Fedora 12 on a new machine I have a problem: *** glibc detected *** /usr/bin/Xorg: free(): invalid pointer: 0x026bc390 *** === Backtrace: = /lib64/libc.so.6[0x3384674576] /usr/bin/Xorg(XIDeleteAllDeviceProperties+0x33)[0x4e2673] /usr/bin/Xorg[0x425714] /usr/bin/Xorg(RemoveDevice+0x165)[0x426935] /usr/bin/Xorg(DeleteInputDeviceRequest+0x54)[0x479144] /usr/bin/Xorg[0x455c50] /usr/bin/Xorg[0x455cef] /usr/lib64/libhal.so.1[0x339220bb68] /lib64/libdbus-1.so.3(dbus_connection_dispatch+0x336)[0x3389e109d6] /lib64/libdbus-1.so.3[0x3389e10bff] /usr/bin/Xorg[0x4558fb] /usr/bin/Xorg(WakeupHandler+0x4b)[0x43196b] /usr/bin/Xorg(WaitForSomething+0x1d7)[0x45bd97] /usr/bin/Xorg[0x42c3b2] /usr/bin/Xorg[0x421cfa] /lib64/libc.so.6(__libc_start_main+0xfd)[0x338461eb1d] /usr/bin/Xorg[0x4218a9] --- The configuration to reproduce is this computer - switch - hub - keyboard + 2 mice It has also happened to me while docking/undocking the laptop. I can reproduce it reliably (10 switches) with just one mouse without valgrind, but with valgrind I could only reproduce it after adding another mouse. The problem happens both with radeon (desktop) and intel (laptop) drivers. The bug above has some valgrind output attached. The most relevant seems to be: The most relevant log seems to be: ==3808== Invalid write of size 1 ==3808==at 0x4EB6CC: _XkbSetIndicatorMap (xkb.c:3093) ==3808==by 0x4EB933: ProcXkbSetIndicatorMap (xkb.c:3160) ==3808==by 0x42C69B: Dispatch (dispatch.c:445) ==3808==by 0x421CF9: main (main.c:285) ==3808== Address 0x88a8568 is 8 bytes inside a block of size 392 free'd ==3808==at 0x4A04D72: free (vg_replace_malloc.c:325) ==3808==by 0x50AC4E: SrvXkbFreeKeyboard (XKBAlloc.c:289) ==3808==by 0x4FE30D: XkbFreeInfo (xkbInit.c:679) ==3808==by 0x4254C3: FreeDeviceClass (devices.c:671) ==3808==by 0x425656: FreeAllDeviceClasses (devices.c:801) ==3808==by 0x425775: CloseDevice (devices.c:849) ==3808==by 0x426934: RemoveDevice (devices.c:993) ==3808==by 0x479143: DeleteInputDeviceRequest (xf86Xinput.c:671) ==3808==by 0x455C4F: remove_device (hal.c:72) ==3808==by 0x455CEE: device_removed (hal.c:90) ==3808==by 0x339220BB67: filter_func (libhal.c:1067) ==3808==by 0x3389E109D5: dbus_connection_dispatch (dbus-connection.c:) Start of log: ==3808== Memcheck, a memory error detector ==3808== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==3808== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==3808== Command: /usr/bin/Xorg.1 :0 -auth /root/.serverauth.3791 ==3808== X.Org X Server 1.7.1 Release Date: 2009-10-23 X Protocol Version 11, Revision 0 Build Operating System: 2.6.18-164.2.1.el5 Current Operating System: Linux amdbox 2.6.31.9-174.fc12.x86_64 #1 SMP Mon Dec 21 05:33:33 UTC 2009 x86_64 Kernel command line: ro root=UUID=ecf9b10b-b481-4264-9575-b63508588dc4 LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet Build Date: 05 November 2009 07:43:10PM Build ID: xorg-x11-server 1.7.1-7.fc12 Current version of pixman: 0.16.4 Before reporting problems, check http://bodhi.fedoraproject.org/ to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Jan 19 18:04:54 2010 (==) Using default built-in configuration (30 lines) (II) [KMS] Kernel modesetting enabled. Mark ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libpciaccess x86 backend
On Mon, Jan 18, 2010 at 12:37 AM, Samuel Thibault samuel.thiba...@ens-lyon.org wrote: Hello, This adds support on x86 for OSes that do not have a PCI interface, tinkering with I/O ports, and makes use of it on GNU/Hurd. Now this might be a dumb question but how to hurd drivers interact with the PCI layer, they all just bang on it directly? It just seems lazy to add a direct to hw code again in userspace when clearly the kernel should be able for it, not that I really mind, I'm just hoping other OSes don't get this lazy, which marking this code as generic x86 might make them. Dave. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libpciaccess x86 backend
Dave Airlie, le Wed 20 Jan 2010 06:42:30 +1000, a écrit : On Mon, Jan 18, 2010 at 12:37 AM, Samuel Thibault samuel.thiba...@ens-lyon.org wrote: This adds support on x86 for OSes that do not have a PCI interface, tinkering with I/O ports, and makes use of it on GNU/Hurd. Now this might be a dumb question but how to hurd drivers interact with the PCI layer, they all just bang on it directly? There is no Hurd PCI driver (yet). The only PCI code being used is a temporary glue into GNU Mach. Yes, an interface between that and userspace should be designed, etc. But since it's a temporary glue, it's not really worth doing it right now. Still people would like to already try Xorg. It just seems lazy to add a direct to hw code again in userspace when clearly the kernel should be able for it, Depends on the kernel. A kernel could very well not deal with PCI at all and let userspace agree on using a PCI server, that could for instance use libpciaccess. not that I really mind, I'm just hoping other OSes don't get this lazy, which marking this code as generic x86 might make them. I understand your concern. I still believe it is more helpful to provide this in the interim than to let yet another barrier from Xorg support for exotic kernels. Samuel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libpciaccess x86 backend
Corbin Simpson, le Tue 19 Jan 2010 13:26:47 -0800, a écrit : It doesn't seem that exotic to want a PCI layer, and wasn't the entire point of libpciaccess to keep PCI code out of the Xserver? I'm afraid I'm not sure which point you want to make. An exotic kernel would precisely _not_ want to have to fiddle with PCI intrinsics. Also, putting x86 code into libpciaccess in the case there is not PCI layer still keeps the PCI code out of Xserver itself, in a way. Samuel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg crash with input device plug/unplug
On Tue, Jan 19, 2010 at 08:55:59PM +0100, Marko Macek wrote: Originally filed at: https://bugzilla.redhat.com/show_bug.cgi?id=550948 Please have a look at https://bugzilla.redhat.com/show_bug.cgi?id=540584, this issue has been fixed and updated rpm packages are available in updates-testing. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
