Re: [ANNOUNCE] xorg-server 1.10.0
On Fri, Feb 25, 2011 at 09:57:28PM -0800, ext Keith Packard wrote: Here's the final 1.10 release. Since RC3, we've had a few build fixes made, and one regression fixed (a crasher on sparc and other architectures). A complete changelog since 1.9.0 for your amusement. Not surprisingly, Peter Hutterer had the most commits this time around, although Adam Jackson nearly caught him with a last-minute sequence of compiler warning fixes. Thanks, as always, to the whole X org community for contributing to this release. And here's a bit more detailed how we all performed in 1.10 window: http://vignatti.wordpress.com/2011/02/28/x-census-for-1-10/ Jon C and others could be interested in getting some few updates for gitdm from X community. Please let me know if you have some concerns: http://cgit.freedesktop.org/~vignatti/gitdm And, indeed, thanks all for the contributions! Tiago ___ 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: [ANNOUNCE] xorg-server 1.9.99.901
On Mon, Dec 06, 2010 at 09:04:22PM -0800, ext Keith Packard wrote: Ok, I think we've done enough damage for one release. Thanks everyone for pulling a long weekend to get changes prepared and reviewed. We're still missing the threaded input stuff, but that needs more review and I think we wore Tiago out this time around. If someone wants to propose merging it after the freeze, I think we should consider doing it. Note that this tarball depends on unreleased protocol packages for xext and randr. It should correctly whine if they aren't available. Keith, there's still Haitao trying to integrate DRI2 for Xephyr for awhile. I had ping you but never heard anything back: http://lists.x.org/archives/xorg-devel/2010-November/014904.html http://lists.x.org/archives/xorg-devel/2010-October/014562.html I'm wondering what your plans for that or at least a feedback to give him. Thank you, Tiago ___ 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: 3MB Memory Leak in KDrive Xfbdev
Hi, On Mon, Nov 01, 2010 at 11:45:57AM +0530, ext vrushali shinde wrote: Hello All, I need to fix memory leak issue urgently, any inputs regarding this would very useful to me. Thanks again. Kdrive development is practically dead. We just have some few people working on Xephyr backend and the other hw servers are due to be extinct. To substitute kdrive + fbdev you can try Xorg + fbdev driver which should be all the work you need. On Wed, Oct 27, 2010 at 4:33 PM, vrushali shinde vrushali1...@gmail.comwrote: Hello All, I need to launch XServer in a thread and terminate(release resources and kill thread) XServer whenever required. To achieve this, I have created a shared library of Kdrive-XServer. To start XServer I load the Xserver shared lib, and launch the Xfbdev server in a thread. For terminating Xserver, I callGiveUp (0); function, that releases the XServer resources, then I dlclose on Xserver library. However, when I start and terminate XServer in above way, there seems to happen 3MB of memory leak in every cycle. After narrowing down it is seen that following 2 function calls increase the memory to 3M at start and is not release at termination. The functions are: InitInput(argc, argv); and InitAndStartDevices(); These are the observation on ARM target board. When above scenario is simulated on x86 machine, and Valgrind is run, it does not show memory leaks in above mentioned functions, instead it shows definite loss of 1,244 bytes of memory in KdInitOutput() and some other minor definite losses. I need to find out the 3M memory loss on target ARM board for InitInput(argc, argv); and InitAndStartDevices(); functions. For this I did try to release memory allocations in InitInput(), but no success. If I comment below lines from KdProcessArgument(), then the 3M chunk leak does not happen however with this mouse and keyboard are not initialized and I need to have keyboard and mouse. Can anyone help me out to find out the 3M chunk and how to avoid it / release it? -- KdAddConfigKeyboard(keyboard,/dev/tty0); KdAddConfigPointer(mouse,/dev/input/mice); kdHasPointer = TRUE; kdHasKbd = TRUE; In addition to information below, I also get get following error when closing VT Cant deallocate console... Can this error contribute to some or all of the 3M memory leak? Please let me know if anyone has got any clue about this or have faced simlar issue. Thanks in advance, Vrushali ___ 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: tiago.vigna...@nokia.com Tiago ___ 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: [ANNOUNCE] xorg-server 1.9.0
On Sat, Aug 21, 2010 at 02:44:37AM +0200, ext Keith Packard wrote: Welcome to X server version 1.9.0. I ran gitdm again and got some pretty numbers for this release. I posted in my blog: http://vignatti.wordpress.com/2010/09/02/x-census-for-1-9/ Hope y'all like it :) Tiago ___ 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: Zapping the Xorg server
On Thu, Aug 26, 2010 at 04:50:18PM +0200, ext Alex Deucher wrote: On Thu, Aug 26, 2010 at 5:16 AM, Wolfgang Draxinger wdraxinger.maill...@draxit.de wrote: On Thu, 26 Aug 2010 16:25:04 +0900 Miles Bader mi...@gnu.org wrote: (...) Only instead, it kills your X server... :( Ouch... Well, using Vim (and I preferably in uxterm) one is kind of protected from loosing changes by putting things into a screen session (but of course all the other non-text-console programs will loose their stuff). Seeing a lot of Emacs users using XEmacs or GNU Emacs in X mode that obviously won't work. Which brings me to something I always wondered about: Why is there no X pendant for screen (or I'm not aware of it)? I.e. some proxy X server, opening an additional display passing through X transparently, keeping record of prerequisite resources. And make this proxy de-/attachable. So far I emulated such using Xvnc, but that means no HW acceleration, no indirect GLX and such things. Of course such a thing boils down to implementing an almost fully featured X server, so if I were to implement such a thing, I'd probably start of kdrive/Xephyr. There was a GSOC project to implement screen-like functionality for X a few years ago, but it ended up being a lot more complex than anyone thought at the beginning and thus was never completed. xpra and xmove also are not that far from this idea. Tiago ___ 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: xorg and int10: problem
On Mon, Aug 16, 2010 at 09:33:07PM +0200, ext Francisco P Kaseker wrote: Hello =] My system: pci-e card: via, driver openchrome pci: sis, driver sis, 315pro pci: sis, driver sis, 315pro system: ubuntu 10.04 updated, X.Org X Server 1.7.6, Release Date: 2010-03-17 Problem: I need to initializate my VGA cards with INT10 disabled and after that I need do enable INT10 for them. Old solution: Previously I could to use -probleonly option to open X with INT10 NO and after that X -config xorg.conf etc But nowadays X doesn't has this option. Why I need this: Because I need to open one xserver and many Xephyr to create multiterminals with MDM (Multiseat Display Manager by C3SL). Important: I need to use INT10 NO before because sis 315pro has many problems (i know, it's very old card and has very old drivers) Question: If I couldn't use -probleony option, witch alternative I have do solve this problem? I'd guess 'Xorg -pogo' pretty much simulates -probleonly (note -pogo option is not documented). Cheers, Tiago ___ 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: X lib support for embedded systems.
On Wed, Aug 11, 2010 at 06:49:01AM +0200, ext Piotr Gluszenia Slawinski wrote: http://83.18.229.190/minimalistix_linux/static-binaries/XF86_SVGA this one is static binary which is pretty old and has ~4M footprint, and since then i could not build either anything smaller, or anything which would perform better, even though i've tried many times. FYI, I have a Xorg 1.9 RC4 running with 4.3 MB of RSS in my device. Tiago ___ 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: X lib support for embedded systems.
On Wed, Aug 11, 2010 at 10:19:55AM +0200, ext Praveen J C (RBEI/EST1) wrote: Also I came across kdrive.. but they its obsolete? is it true? yes, in short kdrive hardware servers are obsolete. Tiago ___ 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: X lib support for embedded systems.
On Tue, Aug 10, 2010 at 01:59:32PM +0200, ext Praveen J C (RBEI/EST1) wrote: Basically X11 and fltk must occupy not more than 20MB! I found interesting that your biggest concern here is storage. That's _really_ cheap nowadays! Tiago ___ 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] os: Don't write the reply that overflows output buffer
On Tue, Aug 03, 2010 at 03:25:29PM +0200, ext Kristian Høgsberg wrote: Cleaning up X code that works isn't my kind of fun. ahaa, I knew that! And it's one of the reasons you started Wayland :) Tiago, having fun trashing X code ___ 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: Is this an X bug?
On Mon, Aug 02, 2010 at 07:45:54PM +0200, ext Adam Jackson wrote: On Mon, 2010-08-02 at 12:21 -0400, Bob Self wrote: I'm running Ubuntu linux and am getting lockups. When it 'locks up' sometimes I can login via ssh, sometimes everything is halted. When I can log in I always find that X is stuck at 100% cpu. I have found this in /var/log/Xorg.0.log.old after rebooting via a ssh connection. [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e937b] 1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80e8b6b] 2: /usr/bin/X (xf86PostButtonEventP+0xcf) [0x80c29cf] 3: /usr/bin/X (xf86PostButtonEvent+0x6c) [0x80c2a7c] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0x7d4000+0x4c67) [0x7d8c67] 5: /usr/bin/X (0x8048000+0x6d5bf) [0x80b55bf] 6: /usr/bin/X (0x8048000+0x122744) [0x816a744] 7: (vdso) (__kernel_sigreturn+0x0) [0x149400] Does anyone know what this means? You stopped the backtrace just before it got interesting. All we see there is the SIGIO signal handler being entered and calling into the input driver, which then tries to eat an event from the kernel and has no place to put it because the core server is stuck not processing input events. So whatever's going on in stack frame 8 is to blame. In other words, it's very likely your driver messed your graphics device that got stuck somewhere while the input signal handler keeps queueing input events. So almost sure video driver issue. Tiago ___ 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: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 08:16:34PM +0200, ext Greg KH wrote: Note, I have a bunch of the xorg developers already in our main gitdm configuration file due to me running the numbers a long time ago for a Linux Plumbers conference talk. I think it's somewhere public as well, but I can't find it at the moment. Do you want me to merge what you have done here with that file? So did you find the file? Those trivial patches in gitdm were cooked in a way that lets the kernel stats live nicely. You can grab those either if you want. Thanks, Tiago ___ 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: [ANNOUNCE] xorg-server 1.8.99.904
On Thu, Jul 01, 2010 at 07:24:25PM +0200, ext Greg KH wrote: On Thu, Jul 01, 2010 at 06:45:48PM +0300, Tiago Vignatti wrote: [0] On the top of the Jonathan's tree I applied some patches concerning X.Org. I'm cc-ing him also who might be interested to fetch it: ttp://cgit.freedesktop.org/~vignatti/gitdm/ I think you ment: http://cgit.freedesktop.org/~vignatti/gitdm/ yep! :) git://anongit.freedesktop.org/~vignatti/gitdm $ git clone git://anongit.freedesktop.org/~vignatti/gitdm Initialized empty Git repository in /home/gregkh/tmp/gitdm/.git/ remote: Counting objects: 153, done. remote: Compressing objects: 100% (71/71), done. remote: Total 153 (delta 76), reused 153 (delta 76) Receiving objects: 100% (153/153), 44.46 KiB, done. Resolving deltas: 100% (76/76), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. Are you sure you set that up correctly? ooops. Should be fixed now. Thanks for checking this all! Tiago ___ 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] libXfont 1.4.2
This minor release contains a new and single hook function to be used by the server to register all fpe functions (register_fpe_functions()). Also, lot of clean-ups for configuration happened. PS: my first release. Yay! Alan Coopersmith (1): Update Sun license notices to current X.Org standard form Gaetan Nadon (15): .gitignore: use common defaults with custom section # 24239 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 Deploy the new XORG_DEFAULT_OPTIONS #24242 INSTALL, NEWS, README or AUTHORS files are missing/incorrect #24206 configure.ac: AM_MAINTAINER_MODE missing #24238 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES config: replace custom code with reusable macro XORG_WITH_XMLTO doc: use new macros to control doc generation doc: specify 0.0.20 as the minimum version for xmlto config: remove protection for AS_HELP_STRING for old autoconf config: remove the pkgconfig pc.in file from EXTRA_DIST config: replace obsolete AM_CONFIG_HEADER with AC_CONFIG_HEADERS Revert config: replace obsolete AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: replace obsolete AM_CONFIG_HEADER with AC_CONFIG_HEADERS config: fontconf.h.in is redundant in EXTRA_DIST Tiago Vignatti (2): Use one single function to register fpe functions libXfont 1.4.2 Yaakov Selkowitz (1): Add -lbz2 to Libs.private if bzip2 is enabled git tag: libXfont-1.4.2 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.4.2.tar.bz2 MD5: 503911759734998f9235b926eed82eb8 libXfont-1.4.2.tar.bz2 SHA1: 79c2089fec014da4b7976e6762f1e9e447fd5767 libXfont-1.4.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.4.2.tar.gz MD5: 6e530c84d10dd5b053007e7623d2f88d libXfont-1.4.2.tar.gz SHA1: 959aaab2dda8f49455d421317905a177a15d49aa libXfont-1.4.2.tar.gz Tiago signature.asc Description: Digital 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
Re: mouse in zaphod mode on radeon
On Sun, Apr 04, 2010 at 01:44:29PM +0200, ext Attila Kinali wrote: Moin, After the recent updates of the radeon driver i thouht i'd try zaphod mode again. I must say i'm very happy that it works nearly perfect now. There is only one little issue left. If i use the following configuration of the server layout: --- Section ServerLayout Identifier Default Layout Screen Screen 1 Screen Screen 2 RightOf Screen 1 InputDevice Generic Keyboard InputDevice Configured Mouse EndSection --- Then the second screen is mapped on the right side of the first screen (how it should). The mouse is initially on the first screen. I can move my mouse to the right, from the first screen to the second screen (all fine until now). But if i try to move the mouse back from the second screen to the first one, it gets blocked at the edges of the second screen. i.e. i cannot move it back to the first screen. Interestingly, if i use anything else then RightOf in the config above (ie LeftOf, Above or Below) i cannot move the mouse from the first screen to the second at all. I thought that it must be some simple check of the cursor position that is not correctly done and tried to fix it myself, but got lost in the code and couldnt figure out where the bug comes from. :-( I'd appreciate if someone could help me out here. Distro is debian/testing, Xorg version is 7.5 xorg-core: 1.7.5 xorg-ati: 6.12.6 xorg.conf and Xorg.0.log are attached. You might be using a version of the server without this patch bellow: commit f9a2fff2248d7254958857677cabfea914ed4853 Author: Tiago Vignatti tiago.vigna...@nokia.com Date: Wed Aug 5 21:02:29 2009 +0300 mi: fix cursor warping screens The server was processing ET_RawMotion type when the cursor was wrapping to another screen and getting wrong valuator values. This fix such issue considering only ET_Motion, ET_KeyPress, ET_KeyRelease, ET_ButtonPress and ET_ButtonRelease types when the cursor detects a new screen, keeping the normal processing of device events. Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Tiago ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: 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
Re: Multiseat with VGAArbiter on 2 Radeon cards
On Fri, Dec 04, 2009 at 09:00:19PM +0100, ext Steffen Schaumburg wrote: Hi everyone, I'm trying to setup multiseat with 2 radeon cards using the new-ish VGA arbiter thing. The latest info I could find about it is dated July and said that one needs to get certain things from git but since linux 2.6.32 has arbiter I figured I give it a go. So I guess here is my first question really: should this work with current release versions of X etc.? yes. And the log says you're indeed using it. The current status of my work is: From pressing the power button to kdm loading it displays in low-res on just the monitor on the primary card. This is how it used to be when I had just one card and I don't mind. Then when kdm starts it turns the second monitor on (so far so good) but then nothing. The primary monitor loads kdm as expected but the second one stays on but black. It doesn't go into standby even after hours. I tried swapping the monitors in kdmrc and it does exactly that - after the swap the secondary monitor loads kdm as wanted, but the primary monitor now turns on but stays black. This is the configuration I'm using now. humm, seems not issue with vga arbitration. I'd guess maybe missed mode setting. Try to start an app on the monitor black and see if connects. If this succeeds then the arbiter is doing its job okay. Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: VT switch event
Andriy Gapon wrote: Does X server send any event to its clients on VT switch? In other words, is it possible for a client to get notified of such event? Or is it totally transparent? no, no event is send from the X server. But why you want that? Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: CT ct65545 problem
Yan Seiner wrote: I have a very, very old laptop - 1995 vintage - that I want to repurpose for a net-terminal. It has a Chips and Technologies 65545 video chipset. This works with X as I've run it in the past with both freeBSD and an older version of linux (something with a 2.4 kernel and an old version of xfree.) I decided to upgrade this to a current version to get some net tools. Now I can't get X to recognize the CT chipset. I am using xorg 7.4, with the chips driver. X fails with: (II) Primary Device is: ISA (EE) No devices detected Unfortunately I don't have pcmcia working either so I can't copy and paste quite yet. I suspect that the driver cannot auto-probe the ISA bus and it's looking for some sort of IRQ or base address. But how do I go about finding this? I don't recall having to do anything special in the past, but who knows recently versions of the server don't support ISA anymore. Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Blank screen on starting X
On Tue, Sep 15, 2009 at 04:24:15PM +0200, ext Flittigs at PICT wrote: Hello all, we are undergrad students trying to install and compile the latest X release on a virtual box. We did all installation on /opt/MPX prefix. on doing sudo /opt/MPX/bin/X -config /../xorg.conf , the X server starts running and screen goes blank. We also changed the startx script to accomodate the new path for X. Can anyone help on this? thanks -- just in case: adding -retro on the arguments does the job? :) Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Issues with X Server Compilation on Virtual box
Hi, On Mon, Sep 14, 2009 at 12:11:23PM +0200, ext mrinal nargunde wrote: We are undergraduate students trying to install X Server on virtual box. We have installed all required packages. After running the startx command, we got the following error in the log: (++) Using config file: /etc/X11/xorg.conf dlopen: /opt/MPX//lib/xorg/modules/drivers/vboxvideo_drv.so: undefined symbol: resVgaShared (EE) Failed to load /opt/MPX//lib/xorg/modules/drivers/vboxvideo_drv.so (EE) Failed to load module vboxvideo (loader failed, 7) (EE) No drivers available. Fatal server error: no screens found To get the vboxvideo driver, we also compiled virtualbox and did a symbolic link to the certain .so drivers... But it din't help. Your vboxvideo driver is not aware already about the removal of RAC, that we've done recently. Where are the sources of the driver (and is there some reason for the driver doesn't live on freedesktop.org?)? It's pretty easy to fix this issue. Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem building xserver 1.5.1
On Tue, Aug 04, 2009 at 02:39:44PM +0200, Diego A. Fons wrote: In file included from linuxPci.c:271: /usr/include/linux/pci.h:453: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pci_power_t' linuxPci.c:553: warning: no previous prototype for 'xf86AccResFromOS' I'm crosscompiling for ARM in a scratchbox environment: I'd guess that your ARM device doesn't has PCI hardware. So why you're compile PCI related stuff there? :) /sarcasm Try to avoid old X version and go for upstream (or close) code. We're doing a really nice clean up on this PCI and related things. Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: damage is only used with DRI
pushed. Thank you.
On Sun, Jul 05, 2009 at 04:44:59PM +0200, extralov...@mail.nokia.com wrote:
Would someone please review this?
Thanks,
Kristof
On Mon, Jun 29, 2009 at 16:08, RALOVICH,
Kristófkristof.ralov...@gmail.com wrote:
Compile tested.
Please review and apply.
Thanks,
Kristof
From 903dcd1692d4857e50f7ac6b073092d952a251ac Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Mon, 29 Jun 2009 15:52:06 +0200
Subject: [PATCH 2/2] glx: damage is only used with DRI
---
glx/glxdrawable.h | 2 --
glx/glxdri.c | 1 +
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/glx/glxdrawable.h b/glx/glxdrawable.h
index 0215b3b..3f165ed 100644
--- a/glx/glxdrawable.h
+++ b/glx/glxdrawable.h
@@ -35,8 +35,6 @@
* Silicon Graphics, Inc.
*/
-#include damage.h
-
/* We just need to avoid clashing with DRAWABLE_{WINDOW,PIXMAP} */
enum {
GLX_DRAWABLE_WINDOW,
diff --git a/glx/glxdri.c b/glx/glxdri.c
index 5fb75a4..c9d226b 100644
--- a/glx/glxdri.c
+++ b/glx/glxdri.c
@@ -38,6 +38,7 @@
#include windowstr.h
#include os.h
+#include damage.h
#define _XF86DRI_SERVER_
#include drm_sarea.h
--
1.6.3.3
Content-Description: ATT1.txt
___
xorg-devel mailing list
xorg-de...@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Tiago
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] glx: remove Xgl leftover
pushed. Thank you.
On Sun, Jul 05, 2009 at 04:37:04PM +0200, extralov...@mail.nokia.com wrote:
Would someone please review this?
Thanks,
Kristof
On Mon, Jun 29, 2009 at 15:23, RALOVICH,
Kristófkristof.ralov...@gmail.com wrote:
Compile tested and grep found no references.
Please review and apply.
Thanks,
Kristof
From 21c6b89d0bba8efff847b6e88cbb76dc1d05d598 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?RALOVICH,=20Krist=C3=B3f?= tad...@freemail.hu
Date: Mon, 29 Jun 2009 15:18:56 +0200
Subject: [PATCH] glx: remove Xgl leftover
GlxSetRenderTables was only used by the long gone Xgl.
---
glx/glxcmds.c | 6 --
glx/glxserver.h | 3 ---
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index d4ff7da..f5632d1 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -51,12 +51,6 @@
#include indirect_table.h
#include indirect_util.h
-void
-GlxSetRenderTables (struct _glapi_table *table)
-{
- _glapi_set_dispatch (table);
-}
-
static int
validGlxScreen(ClientPtr client, int screen, __GLXscreen
**pGlxScreen, int *err)
{
diff --git a/glx/glxserver.h b/glx/glxserver.h
index 3e44b71..46c9382 100644
--- a/glx/glxserver.h
+++ b/glx/glxserver.h
@@ -94,9 +94,6 @@ void GlxExtensionInit(void);
void GlxSetVisualConfigs(int nconfigs,
void *configs, void **privates);
-struct _glapi_table;
-void GlxSetRenderTables (struct _glapi_table *table);
-
void __glXScreenInitVisuals(__GLXscreen *screen);
/*
--
1.6.3.3
Content-Description: ATT1.txt
___
xorg-devel mailing list
xorg-de...@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Tiago
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xf86-video-geode: fix GPIO BAR detection with libpciaccess
Andres Salomon escreveu: This patch fixes an issue with the GPIO BAR detection. Basically, with libpciaccess we're finding the ISA device and checking its BARs, Well at least the description is wrong: ISA has fixed address mappings and doesn't use BARs. Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
Hugo Vanwoerkom escreveu: Matt Price wrote: hi, snip So i'm wondering: does anyone out there have a multiseat system that actually can suspend and hibernate successfully? And if so, do you use the -sharevts switch when starting X, or do you have some other trick for getting the x sessions to display simultaneously? Hi Matt, I run a two-seater but never got suspend/hibernate to work. Did you make progress? Mix this kind of things (suspend/hibernate + multiseat) can be explosive. Don't do that - at least until the KMS, with rootless servers, definitely arrives. Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multiseat, -sharevts, and suspend/hibernate
McDonald, Michael-p7438c escreveu: I'm confused. What does rootless servers have to do with multiseat? In the current implementation, multiseat implies in several servers in parallel, which in turn implies in hardware accesses in parallel (mostly not coordinated by anyone), which in turn mess your system. Uoow! Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
Hi, martin f krafft escreveu: 3. When moving the mouse from head to head, the old pointer is left on the edge of the head we just left, and stays there while a new pointer moves about on the entered head. When moving back, the new pointer stays at the edge, and the old pointer is resumed. Yeah, I saw it here as well. But this is usually easy to fix. Find which commit caused the bug with a binary search in the tree (man git-bisect). I'd guess something inside mipointer.c Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
Alex Deucher escreveu: On Tue, Apr 28, 2009 at 3:07 PM, martin f krafft madd...@madduck.net wrote: Your best bet short term is to use xserver 1.4.x. Any idea how long that short term is? 1.4.x works fine for me at the moment, but I'd rather not build on that basis for indeterminate time... Hard to say, depends on when the work gets done. The universal fix would be to get int10 and vga stuff working with libpciaccess, which on Linux at least, requires a kernel vga arbiter. Not sure about other OSs. radeon specific fixes would be to fix the non-int10 post code in the radeon driver or switch to the kms/mm enabled radeon drm and fix up any multi-card issues that may be lurking there. Yeah, I'm trying to solve part of this. Martin, if you want to help in some way, test this patch and see if it works, please: http://lists.x.org/archives/xorg-devel/2009-April/000794.html Thank you, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and multiple graphics cards
Hi Timothy, Timothy S. Nelson escreveu: Can I point out that https://bugs.freedesktop.org/show_bug.cgi?id=20816 and its dependencies are the appropriate bugs for the issue? Not that I want to discourage mailing list comment, or anything, but merely to point any relevant people at what's already been done, and what hasn't. Yes, please feed that bug. And if you like to do that, I also have a list here of related bugs :) https://bugs.freedesktop.org/show_bug.cgi?id=18160 https://bugs.freedesktop.org/show_bug.cgi?id=18839 https://bugs.freedesktop.org/show_bug.cgi?id=18321 https://bugs.freedesktop.org/show_bug.cgi?id=20849 https://bugzilla.redhat.com/show_bug.cgi?id=454864 Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: After an update I get error message no screens found
rosenrei...@arcor.de escreveu: Hi, I updated my system and after a reboot the Xserver failed to start. I got the message: (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found I tried the new unmodified xorg.conf and my old working xorg.conf (attached) configuration and I got the same error (logfile attached). What's wrong? rm -rm xorg.conf and start the X server again. Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building and Installing an older Release e.g. Xorg 7.2
Dieter und Sigrid Henskes escreveu: I wish to install Xorg 7.2 on my system ( Linux Kernel 2.6.27.7-9 - SUSE 11.1 ) as the mga driver does not support 7.4. I'm using a Matrox G550 AGP here with 7.4. Send the logs files to us, please. Cheers, Tiago ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] Patch series: switching to internal events
Peter Hutterer escreveu: git://people.freedesktop.org/~whot/xserver.git internal-events The current X server implementation uses the protocol wire format for input event processing. This goes from event generation in GetPointerEvents() and friends through to the actual event delivery. Thus, the server is bound internally to a 32-byte wire format + the two GenericEvents we have atm, with random if/then/else/other sprinkled to deal with core, XI and GenericEvents. Adding new events for XI2 is painful, as we have to extrapolate new information from structs that don't have them. And sprinkle more if/else/misc across the code. This patch series introduces a new InternalEvent, visible only to the server. Event generation and most of the event processing now only uses this InternalEvent. Towards the end of event delivery, we switch back into core/XI events. Arguably, this could be pushed even further but requires a rework of the mess that constitutes event masks. I've been running versions of it during development, and put some effort in to make all commits run-able (for future bisecting). They're rebased onto today's master. Casualties: custom event handlers, DGA, event callbacks are broken for now. No reason they can't be fixed, I just didn't bother yet. Comments and testing much appreciated. I don't what would be the overhead of this approach but maybe we can win some performance doing all 'switch' in eventconvert.c as a vector of pointers. Something like tables.c. Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Proper way to enable port access tracing with current xserver
Alex Villacís Lasso escreveu: From what I glean from the traces, it seems that using VESA to start up the primary Savage chipset works correctly. However, when trying to initialize the Oak chipset as secondary (just that one, without reference to the primary Savage chipset), it ends up in a loop of in(3da) = ff and hangs. Interestingly, I saw no hint that the Savage chipset was ever moved out of the legacy VGA mapping in order to initialize the Oak chipset via POST. Which ties back to my previous question: what measures (if any) are supposed to be taken by the xserver in order to hand over the legacy VGA ports to a secondary chipset that needs access to them for POST, when run with a different chipset as primary? As in, Savage is mapped to legacy VGA, I want to POST the Oak chipset, which needs a mapping to the VGA ports too, so what should the xserver do? yeah, this is pretty much the task of the vga arbiter. See my next email... -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Proper way to enable port access tracing with current xserver
Hi, Alex Villacís Lasso escreveu: Alex Deucher escribió: So, lets say I want to add this support back. Is this squarely a libpciaccess change, or do I have to place this on the xserver (since this is specifically a VGA requirement)? Is anyone currently working on this, by any chance (just to avoid duplicating work). Any suggestions on the proper API to expose from libpciaccess? Are there any official docs on bridge chipsets, besides the actual source code of old xservers? Ideally it would be done in the kernel to be used with libpciaccess. Tiago and Paulo have been working on it: http://lists.freedesktop.org/archives/xorg/2007-October/029507.html I'm not sure what the current status is. As for documents, your best bet is probably hw reference guides from the vendors who make the PCI chipsets (AMD/VIA/Intel/etc.). Most are available. I have collected a few patches. However, the referenced repositories are now 404. Would it be acceptable to skip a kernel implementation for now and instead just modify xserver/libpciaccess to provide a level of functionality similar to pre-1.5 ? The last informations regarding the arbiter are here: http://wiki.x.org/wiki/VgaArbiter I double-checked the links on this wiki. All looks good. Also, there's a nice reading for you here: http://www.inf.ufpr.br/vignatti/papers/vignatti-wso08.pdf Good luck. Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Proper way to enable port access tracing with current xserver
Hi, Alex Villacís Lasso escreveu: Another question I have is this: as far as I understand, PCI video cards have to run the POST (or do an equivalent operation) in order to execute the chipset-specific hocus-pocus that enables legacy vga port access (0x3c0 through 0x3df). So only one chipset can be mapped into that I/O address range at a time (right?). right. Note that some modern video cards can entirely scape from this legacy VGA crappy. When initializing a secondary card via POST, the real-mode code of the secondary card will also attempt to map its own registers into that range (I would assume). So what steps are taken in the xserver to move the primary card out of the way (if at all) so that the second card initializes properly? What happens if the drivers for both chipsets require some access to the legacy I/O ports in order to perform normal operations? this is currently addressed by the RAC module inside the Xorg server. But this module is selfish and only provides informations to its X server. If you have two or more applications (e.g. X servers) trying to use the VGA registers then the machine will probably hang (maybe not hang, but you will see a lot of crazy things on screen... like the lights of a rave party, or a screen that remembers an Atari game... well, it will depends in the kind of things you'll be smoking). Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
Tomasz Chmielewski escreveu: Tiago Vignatti schrieb: Tomasz Chmielewski escreveu: BTW, I tried the multiseat live CD from http://wiki.c3sl.ufpr.br/multiseat/index.php/Live-CD I like its hardware detection (press F1, left mouse to activate this screen). Indeed, it's nice. Now a question: is there a reason to keep your howto alive in the Web given that it doesn't show anything in special or different compared with the others? It will just confuse the poor users. Let's see what the other options are: According to http://wiki.x.org/wiki/Development/Documentation/Multiseat we have the following pages with Users in mind: 1) http://wiki.c3sl.ufpr.br/multiseat/index.php/Mdm mdm is a nice feature preview, even with a live CD, but just no major distro ships it. And if a major distro doesn't ship some software, it just doesn't exist in a Linux world. Livecd had some flaws as I tested it: - resolutions were not detected properly and I couldn't change them (even xrandr was showing that 1024x768 is the only possible one) - the system didn't reboot as I told it to; it was hanging somewhere at the end waiting for something. These are minor flaws, and perhaps not even mdm related. What I didn't like about mdm is that it doesn't ask if it should really shut down or reboot the machine if there are other users logged in (for example, KDM does that, it is nice IMO). 2) http://en.wikipedia.org/wiki/Multiseat - wikipedia article. It's a good explanation, but it won't configure your Linux desktop to be a multiseat station. 3) http://www.ltn.lv/~aivils/?proj_id=multiseatmenu_id=1 - as big fat words say, DONT TRY THIS!, so let's just not go there. 4) http://www.tldp.org/HOWTO/XFree-Local-multi-user-HOWTO/ - very old documentation. DONT TRY THIS! It is here just for historical purposes. OK, so another antiquated documentation. I actually tried to read this, well, but yes, I agree with DONT TRY THIS words now. So what did we have there - nothing usable for a mere mortal, rather scary words that multiseat should not be used. Let's look here now: http://wpkg.org/Configuring_multiseat_X_workstation It's far from being perfect, but at least: - does not tell you you have to patch and compile your brand new 2.4 kernel, because otherwise, multiseat is not possible - doesn't tell you to install a modified XFree86 server - is easy to follow and will work for majority of users who ever edited their xorg.conf in the past So sorry, but if anything's confusing the poor users, it's that wiki.x.org page that lists old documentation which is even not applicable today. Or did you mean, there is some other documentation listed elsewhere? I'd be glad to hear about it. Of course, the whole discussion would be unnecessary if the distros shipped a tool - other than a text editor - for configuring multiseat; but so far, I don't know any distro that does (despite numerous user requests; perhaps not enough though). okay, Tomasz. I updated our wiki [0]. Please take a look there and see if it's reasonable and fits with your ideas. BTW, you didn't give credits and/or referenced anyone in your page. [0] http://wiki.x.org/wiki/Development/Documentation/Multiseat Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
Peter Hutterer escreveu: On Tue, Jan 06, 2009 at 08:05:26AM +0100, Tomasz Chmielewski wrote: 3) http://www.ltn.lv/~aivils/?proj_id=multiseatmenu_id=1 - as big fat words say, DONT TRY THIS!, so let's just not go there. 4) http://www.tldp.org/HOWTO/XFree-Local-multi-user-HOWTO/ - very old documentation. DONT TRY THIS! It is here just for historical purposes. OK, so another antiquated documentation. I actually tried to read this, well, but yes, I agree with DONT TRY THIS words now. If both of them are DON'T TRY THIS, why are they listed on the wiki again? Chances are that if someone comes to the xorg wiki they want to get it to run on their machine. For historical references they should rather go to wikipedia or google or something. Indeed. I've changed it. Thanks Peter, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/4] DRM: in-kernel cursor update on the top of mode setting.
This commit adds support for the DRM in-kernel cursor mode setting APIs.
When drm_mode_setcrtc is called we also initialize the cursor routines.
Through drmCursorSetDev, the userspace app (e.g. Xorg, wayland) tells which
devices are responsible for cursors' updates and the kernel input layer
will spit the events to DRM (drm_collect_input_event). DRM will take
care about the event informations and also screen limits, and then will
draw the cursor on screen.
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
libdrm/xf86drm.c | 20
libdrm/xf86drm.h |4 +
libdrm/xf86drmMode.c |4 +-
linux-core/Makefile.kernel |4 +-
linux-core/drm_crtc.c |3 +
linux-core/drm_crtc.h |4 +
linux-core/drm_cursor.c| 214
linux-core/drm_cursorP.h |1 +
linux-core/drm_drv.c |2 +
shared-core/drm.h | 11 +++
10 files changed, 264 insertions(+), 3 deletions(-)
create mode 100644 linux-core/drm_cursor.c
create mode 100644 linux-core/drm_cursorP.h
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index 7b67813..b8f12b6 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -2994,3 +2994,23 @@ int drmDropMaster(int fd)
ret = ioctl(fd, DRM_IOCTL_DROP_MASTER, 0);
return ret;
}
+
+int drmCursorSetDev(int fd, char *name)
+{
+struct drm_mode_cursor_setdev arg;
+
+strncpy(arg.name, name, strlen(name));
+arg.name[strlen(name)] = '\0';
+
+return ioctl(fd, DRM_IOCTL_MODE_CURSORSETDEV, arg);
+}
+
+int drmCursorHotspot(int fd, int hotx, int hoty)
+{
+struct drm_mode_cursor_hotspot arg;
+
+arg.hotx = hotx;
+arg.hoty = hoty;
+
+return ioctl(fd, DRM_IOCTL_MODE_CURSORHOTSPOT, arg);
+}
diff --git a/libdrm/xf86drm.h b/libdrm/xf86drm.h
index 35780ac..04b7faa 100644
--- a/libdrm/xf86drm.h
+++ b/libdrm/xf86drm.h
@@ -663,6 +663,10 @@ extern void drmCloseOnce(int fd);
extern int drmSetMaster(int fd);
extern int drmDropMaster(int fd);
+/* In-kernel cursor update routines */
+extern int drmCursorSetDev(int fd, char *name);
+extern int drmCursorHotspot(int fd, int hotx, int hoty);
+
#include xf86mm.h
#endif
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index c3921ee..e3a1c76 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -325,7 +325,9 @@ int drmModeMoveCursor(int fd, uint32_t crtcId, int x, int y)
arg.x = x;
arg.y = y;
- return ioctl(fd, DRM_IOCTL_MODE_CURSOR, arg);
+/* Just to see that we're doing the things correctly :)
+ * return ioctl(fd, DRM_IOCTL_MODE_CURSOR, arg); */
+return 1;
}
/*
diff --git a/linux-core/Makefile.kernel b/linux-core/Makefile.kernel
index 246c0b3..53f5795 100644
--- a/linux-core/Makefile.kernel
+++ b/linux-core/Makefile.kernel
@@ -7,8 +7,8 @@
# $XFree86:
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Makefile.kernel,v
1.18 2003/08/16 17:59:17 dawes Exp $
#
-drm-objs:= drm_auth.o drm_bufs.o drm_context.o drm_dma.o drm_drawable.o \
- drm_drv.o drm_fops.o drm_ioctl.o drm_irq.o \
+drm-objs:= drm_auth.o drm_bufs.o drm_context.o drm_cursor.o drm_dma.o \
+ drm_drawable.o drm_drv.o drm_fops.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
drm_sysfs.o drm_pci.o drm_agpsupport.o drm_scatter.o \
drm_memory_debug.o ati_pcigart.o drm_sman.o \
diff --git a/linux-core/drm_crtc.c b/linux-core/drm_crtc.c
index 7ee3321..e015342 100644
--- a/linux-core/drm_crtc.c
+++ b/linux-core/drm_crtc.c
@@ -33,6 +33,7 @@
#include drm.h
#include drmP.h
#include drm_crtc.h
+#include drm_cursorP.h
struct drm_prop_enum_list {
int type;
@@ -1412,6 +1413,8 @@ int drm_mode_setcrtc(struct drm_device *dev,
set.fb =fb;
ret = crtc-funcs-set_config(set);
+drm_cursor_init(crtc);
+
out:
kfree(connector_set);
mutex_unlock(dev-mode_config.mutex);
diff --git a/linux-core/drm_crtc.h b/linux-core/drm_crtc.h
index bfccdeb..15e9aca 100644
--- a/linux-core/drm_crtc.h
+++ b/linux-core/drm_crtc.h
@@ -676,6 +676,10 @@ extern int drm_mode_setcrtc(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_cursor_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
+extern int drm_mode_cursor_setdev_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+extern int drm_mode_cursor_hotspot_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
extern int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_rmfb(struct drm_device *dev,
diff --git a/linux-core/drm_cursor.c b/linux-core/drm_cursor.c
new file mode 100644
index 000..832e3b1
--- /dev/null
+++ b/linux-core/drm_cursor.c
@@ -0,0 +1,214
[PATCH 2/4] X server: dricursor implementation using the X server as application.
This implementation gives two ioctls APIs (DRICursorSetDev, DRICursorHotspot)
to interface with the DRM modesetting cursors. For now this patch disables
the pointer acceleration scheme.
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
Makefile.am|1 +
configure.ac |4 ++-
dix/getevents.c|2 +
dricursor/Makefile.am |9 +++
dricursor/dricursor.c | 51
hw/xfree86/common/xf86Xinput.c |8 ++
hw/xfree86/ramdac/xf86Cursor.c |3 ++
include/Makefile.am|1 +
include/dricursor.h|3 ++
9 files changed, 81 insertions(+), 1 deletions(-)
create mode 100644 dricursor/Makefile.am
create mode 100644 dricursor/dricursor.c
create mode 100644 include/dricursor.h
diff --git a/Makefile.am b/Makefile.am
index aa9c8b6..c641710 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,7 @@ endif
SUBDIRS = \
doc \
+ dricursor \
include \
dix \
fb \
diff --git a/configure.ac b/configure.ac
index 93e3a60..a83da6c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -842,6 +842,7 @@ AC_SUBST([GLX_DEFINES])
AM_CONDITIONAL(DRI, test x$DRI = xyes)
if test x$DRI = xyes; then
+DRICURSOR_LIB='$(top_builddir)/dricursor/libdricursor.la'
AC_DEFINE(XF86DRI, 1, [Build DRI extension])
PKG_CHECK_MODULES([DRIPROTO], [xf86driproto])
PKG_CHECK_MODULES([LIBDRM], [libdrm = 2.3.0])
@@ -1228,7 +1229,7 @@ if test x$XORG = xyes; then
XORG_OSINCS='-I$(top_srcdir)/hw/xfree86/os-support
-I$(top_srcdir)/hw/xfree86/os-support/bus -I$(top_srcdir)/os'
XORG_INCS=$XORG_DDXINCS $XORG_OSINCS
XORG_CFLAGS=$XORGSERVER_CFLAGS -DHAVE_XORG_CONFIG_H
- XORG_LIBS=$COMPOSITE_LIB $FIXES_LIB $XEXTXORG_LIB $GLX_LIBS
$RENDER_LIB $RANDR_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB
$XKB_LIB $SELINUX_LIB
+ XORG_LIBS=$COMPOSITE_LIB $FIXES_LIB $XEXTXORG_LIB $GLX_LIBS
$RENDER_LIB $RANDR_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB
$XKB_LIB $SELINUX_LIB $DRICURSOR_LIB
PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.8.0])
SAVE_LIBS=$LIBS
@@ -1803,6 +1804,7 @@ damageext/Makefile
dbe/Makefile
dix/Makefile
doc/Makefile
+dricursor/Makefile
fb/Makefile
record/Makefile
config/Makefile
diff --git a/dix/getevents.c b/dix/getevents.c
index 4770a69..8d24075 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -880,12 +880,14 @@ GetPointerEvents(EventList *events, DeviceIntPtr pDev,
int type, int buttons,
}
}
else {
+#if 0
if (flags POINTER_ACCELERATE
pDev-valuator-accelScheme.AccelSchemeProc){
pDev-valuator-accelScheme.AccelSchemeProc(
pDev, first_valuator, num_valuators, valuators, ms);
}
+#endif
if(v0) x += *v0;
if(v1) y += *v1;
diff --git a/dricursor/Makefile.am b/dricursor/Makefile.am
new file mode 100644
index 000..017a861
--- /dev/null
+++ b/dricursor/Makefile.am
@@ -0,0 +1,9 @@
+noinst_LTLIBRARIES = libdricursor.la
+
+AM_CFLAGS = @DIX_CFLAGS@ @LIBDRM_CFLAGS@
+
+INCLUDES = $(XORG_INCS) \
+ -I$(top_srcdir)/include
+
+libdricursor_la_SOURCES = dricursor.c
+libdricursor_la_LIBADD = @LIBDRM_LIBS@
diff --git a/dricursor/dricursor.c b/dricursor/dricursor.c
new file mode 100644
index 000..933baac
--- /dev/null
+++ b/dricursor/dricursor.c
@@ -0,0 +1,51 @@
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+
+#include stdio.h
+#include xf86drm.h
+#include dricursor.h
+
+
+int drmFD = -1;
+
+/**
+ * Save the DRM fd. Called by the DRM user, i.e. the video driver.
+ *
+ * @param The drm file-descriptor
+ */
+void
+DRICursorSaveFD(int fd) {
+fprintf(stderr, %s: %d\n, __FUNCTION__, fd);
+drmFD = fd;
+}
+
+/**
+ * drmCursorSetDev ioctl interface.
+ *
+ * Notify DRM about which devices are responsible for cursor updates.
+ *
+ * @param The device path (e.g. /dev/input/event0)
+ * @return On success zero is returned.
+ */
+int
+DRICursorSetDev(char *path)
+{
+fprintf(stderr, %s: %d: %s\n, __FUNCTION__, drmFD, path);
+return drmCursorSetDev(drmFD, path);
+}
+
+/**
+ * drmCursorHotspot ioctl interface.
+ *
+ * When the application updates the sprite, DRM must be notified by the
+ * changes.
+ *
+ * @param The hotspot of the cursor.
+ * @return On success zero is returned.
+ */
+int
+DRICursorHotspot(int hotx, int hoty)
+{
+return drmCursorHotspot(drmFD, hotx, hoty);
+}
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 8eaa118..c4f3f30 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -89,6 +89,7 @@
#endif
#include os.h
+#include dricursor.h
EventListPtr xf86Events = NULL;
@@ -471,6 +472,7 @@ NewInputDeviceRequest (InputOption *options, DeviceIntPtr
*pdev)
DeviceIntPtr dev = NULL;
int rval = Success;
int is_auto = 0
[PATCH 4/4] xf86-video-intel: save drm FD to be used by dri cursor (the shortcut scheme).
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
src/i830_dri.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/i830_dri.c b/src/i830_dri.c
index 07ae646..e9484bd 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -108,6 +108,8 @@ typedef struct drm_i915_flip {
#include dristruct.h
+#include dricursor.h
+
static Bool I830InitVisualConfigs(ScreenPtr pScreen);
static Bool I830CreateContext(ScreenPtr pScreen, VisualPtr visual,
drm_context_t hwContext, void *pVisualConfigPriv,
@@ -674,6 +676,8 @@ I830DRIScreenInit(ScreenPtr pScreen)
return FALSE;
}
+ DRICursorSaveFD(pI830-drmSubFD);
+
/* Now, nuke dri.c's dummy frontbuffer map setup if we did that. */
if (pDRIInfo-frameBufferSize != 0) {
int tmp;
--
1.5.6.3
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multihead / dual input howto (two local users, keyboards etc.)?
Peter Hutterer escreveu: I don't know what other people's view on this is but I'd certainly appreciate it if you could transcribe this to the xorg wiki. It seems the question of multi-seat comes up quite frequently and having a central location to point people at would be helpful. Alternatively, a site on the xorg wiki just linking to various howto's on multi-seat configurations would be a good thing to have too. Currently, a search for multiseat does not show anything. you're right, Peter. I just started a page with some information here. Anyone is very welcome to populate it: http://wiki.x.org/wiki/Development/Documentation/Multiseat Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very bad, and very weird, scrolling text performance xorg 1.5.3 intel 2.5.1 GM965
Johannes Truschnigg escreveu: I really love how Intel and its fine development team supports a free software stack even on the desktop side of things, and how these efforts benefit even users of hardware from different manufacturers. Yet on the other hand, I'd really appreciate more accurate/up-to-date docs about the good stuff that's in the making. It sucks to iterate over some half a dozen developer's blogs every second month or so planet.freedesktop.org is good way to people keep up to date with the news when they are not exactly touching the bits. Most intel guys are subscribed to the planet and they are amazingly updating it. (and yes, we definitely need to separate it in a planet.x.org subset) Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Docs in the modular tree, how to ?
Joao Moreira escreveu: I've downloaded the modular tree using the git_xorg script, as described in the ModularDevelopersGuide wiki page. I see a 'doc' subdirectory, which I've tried to build, it installs a set of .sgml files, these seem to be some X.org docs that I'd like to read... what should I do with this ? I saw that there's also a xorg-sgml-doctools ? it's DocBook files. In my machine this works pretty well: $ sudo apt-get install docbook-utils $ docbook2pdf file.sgml -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: image corruption when in multiseat mode and vga!=normal kernel parameter
Tomasz Chmielewski escreveu: Tomasz Chmielewski schrieb: I have a multiseat system with one AGP card (nvidia GeForce FX 5200; primary card, BIOS displays here) and one PCI card (ATI), running Linux. If I start X in multiseat mode (X on both cards, two keyboards+mice), image is corrupted on nvidia AGP card: The corruption happens with nv, nouveau and binary nvidia driver and a vga= mode different than normal (i.e. vga=791). The corruption does _not_ happen when I don't use vga= parameter (or use vga=normal). The corruption does not happen if I start X only on one of the cards. I replaced the nvidia AGP card for an ATI card and I can see the same corruption. So it doesn't seem to be related to the graphics card or the driver, but some strange issue between the X server and Linux framebuffer? With the current implementation, Multiseat alone already mess the PCI configuration space in some weird ways and for sure that if you try other crazy combinations you're lost. Don't try do that. See: http://lists.freedesktop.org/archives/xorg/2008-November/040400.html Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Making one multiseat user able to switch vts?
Kārlis Repsons escreveu: In general it would be nice, if multiseat workstation administrator could switch to vt[1-6]. Does Xorg support it somehow and is it possible to implement (well, kindly ask someone to do it) such option? Otherwise multiseat on Linux is quite problematic, if no ssh is used... (also I noticed a problem with multiseat, that, if I stop X and login manager permanently, I still could not switch to any vts) It's complicated. Pci-rework, through libpciaccess, cleaned a bunch of the mess that was living in our server. But that wasn't good enough. There's still some issues that don't let us remove the entirely Xorg's pci layer. And this is the point: there's a lot of pci users (VGACon, framebuffer, Xorg and possibly others) in your system fighting for the same piece of hardware. With lucky the kernel based modesetting will let the code more nice and trivial to remove more things from the server. Dave obtained a very nice demo recently starting a rootless X server. Cheers, PS: really, try to avoid a single machine to configure your multiseat box. No one needs text console in our current world. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xephyr - Attach specific mouse device without be root?
Hi,
[EMAIL PROTECTED] escreveu:
Hi all,
I'm playing with using Xephyr for an emulator for the Sugar desktop (OLPC
stuff), I am attempting to bind a specific mouse (event input) to Xephyr
and made had some progress.
However the biggest problem is that I can only get Xephyr to attach an
event source if it is run as root. ie:
--
sudo Xephyr :5 -mouse evdev,,device=/dev/input/event8
--
Is there a method to allow this without being root, but instead as a
normal user without root permissions?
I don't want that others users on the system see everything that I'm
typing. But if you really want that feature, you can play with udev (or
{Console, Device}Kit?) and create some rules for a given group.
As expected the permissions of the event device are 'crw-rw 1 root
root 13, 71 2008-11-12 21:24 /dev/input/event8'
[It seems that a normal Xserver can achieve this when run directly from a
VT, so why not for Xephyr?]
note that you have to get superuser permissions to start a normal X server.
Cheers,
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP / Gnome / KDE / Data transfer / GTK QT / Xorg extension
Hi, Jean-Francois Bouchard escreveu: Problem : We experience very slow scroll speed (lets say, cat /var/log/messages) in Gnome terminal via XDMCP. (1M file : 1.5 minute to display) snip Setup : On the thin client we use ... X Protocol Version 11, Revision 0, Release 7.1.1 Kernel 2.6.18-92.1.17.el5 Gnome 2.16 KDE 3.5 AFAIK, there's no such reason to keep the X clients (Gnome, KDE and etc) on thin-client side. Question : We would like to know if this could be related to X protocol or the way things are handled when drawing text ? If that is easy, you could simply start the same applications on the server, displaying it locally and see if is a network problem. Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP and NAT
Hi, Ritesh Sood escreveu: Hi all, This mail is more of a feature request, and looking at the number of messages on the web, I'm sure quite a number of users would be happy to have this functionality, which is already provided by many commercial Xservers for windows. I want use Xephyr/Xnest on my home machine local_host (as display :1) and have the display controlled by xdm running on a remote application server (app_server) First, please have your browser's font set to a monospaced one so that the boxes below are displayed correctly. Here's how the network topology looks like. +---+ ++ +-+ | local_host| | NAT server | | app_server | | 192.168.0.100 |--- | 1.2.3.4|-| 5.6.7.8 | | running Xnest | || | my.univ.edu | | my.univ.edu | | on display :1 | | my.isp.com | | running xdm | +---+ ++ +-+ At the app_server end, Xaccess contains *.univ.edu NOBROADCAST *.isp.com NOBROADCAST to have some measure of security I'm running xdm as # xdm -debug 1 -config Within the university network of-course, things work very well. From local_host too, at-least XDMCP authentication is happening correctly, i.e. xdm sees that the incoming request is from *.isp.com. and considers it legitimate. Next, it tries to open 192.168.0.100:1 for login window, etc; and that of-course fails. Just to make sure that port forwarding on 60xx ports is happening correctly, I do $ xterm -display my.isp.com:1.0 and that works alright. As i mentioned above, many Xserver implementations for windows provide an option so that the NAT IP address can be passed to xdm instead of XDMCP picking up the local_host address by default. See these FAQs, for instance: http://connectivity.hummingbird.com/support/nc/exceed/exc9003009.html?cks=y http://www.netsarang.com/products/xmg_faq.html It would be great if we could have similar functionality in the Xorg Xservers. Yeah, I would like this kind of feature some time ago as well but seems that our world is finally (not so quickly though) turning to IPv6 [0]. There would be another crazy idea to traverse NAT using hole punching technique. Follow this link: http://vignatti.wordpress.com/2008/03/21/traversing-x11-clients-behind-nat-or-x11-end-to-end-connectivity/ [0] people found another motivation besides the lack of address space which is the energy saving. Seems that NAT must send a keep alive message every 30-180 seconds to keep the address and connection active. It can consume a significant amount of energy, specially for mobile devices. Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Patch 00/02] mieq threading prep
Hi, Jeremy Huddleston escreveu: These are two fairly straight forward patches I'd like to give someone a chance to comment on. In a single-thread Xserver, these patches should have no effect, but they make the code a little more friendly to Tiago's threading patches (and this is what we're already doing in the apple branches). As I already pointed in other occasion, I'm not comfortable enough to push my series of patches to upstream right now. Peter told in a private mail that feels the same. There are probably more critical regions (regarding input properties mainly) that I'm not covered yet (and I'm in the process to finish my masters soon. So I don't want to put another piano on my head). Therefore the real reason now to not push upstream is very simple: multi-thread programming sucks. The first only increments mieqEventQueue.tail when the data is in the queue (since mieqProcessInputEvents assumes the data to be valid if tail is incremented). The second moves a hunk in mieqProcessInputEvents after we increment mieqEventQueue.head, so we don't need to hold a mutex for an unnecessarily. If nobody pipes up in the next few days, I'll be pushing them into master. Right. If the patches are useful for xquartz then both are justified even in the lack of xorg's input thread: Signed-off-by: Tiago Vignatti [EMAIL PROTECTED] Thanks Jeremy, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
Hi Jeremy, Jeremy Huddleston escreveu: Well the problem was that mieqProcessInputEvents DOESN'T use those locks, so it can read the incremented value of miEventQueue.tail thinking that the item at head=tail-1 is ready to read when in fact mieqEnqueue is still in the process of writing to it. Further, mieqEnqueue sometimes edits miEventQueue.tail-1 (when the current and tail-1 events are MotionNotify)... but mieqProcessInputEvents is already reading it. yeah. Now your last patch makes more sense to me (but not that first hunk). For this reason, I went back to locking inside mieqProcessInputEvents with XQUARTZ. Your mutex will lags your cursor update on screen because the input thread will block before enqueuing while the main thread pops events. On this case try to keep the lock near the critical region on mieqPIE, avoiding coarse grained locking. Cheers, PS: this problem of the event queue being processed by more then one user shows how multi-threaded applications suck so much to program. Moreover, if you try to use gdb to debug then you'll see the crazy world that we're living. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
Peter Hutterer escreveu: From: Peter Hutterer [EMAIL PROTECTED] Date: Tue, 4 Nov 2008 15:27:30 +1030 Subject: [PATCH] mi: clean up mieqProcessInputEvents, copy all events before processing. Copy the EventRec's information into local variables before processing them, this should make it safer for upcoming threading and also makes it easier to read. Simplify the event allocation code from the abyss it was before. This also fixes a potential bug where a custom handler could scramble the event before the same -now scrambled- event was then passed through the master's custom event handler. Signed-off-by: Peter Hutterer [EMAIL PROTECTED] Signed-off-by Tiago Vignatti [EMAIL PROTECTED] It's fine for me. Applied and tested here. Thanks, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
Hey,
Jeremy Huddleston escreveu:
Looks good! A recent bug report has surfaced for us since I got rid of
the locking in mieqProcessInputEvents. We need to update
miEventQueue.tail only after the data has actually been pushed into the
tail. This should take care of that problem on master, but I haven't
tested it:
Well, it won't be a problem with Xorg input thread because mieqEnqueue
is tread-safe. There's a mutex protecting writes to the tail pointer in
that function and xquartz will need it as well.
diff --git a/mi/mieq.c b/mi/mieq.c
index 062dede..5016d73 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -122,7 +122,8 @@ mieqResizeEvents(int min_size)
void
mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
{
-unsigned int oldtail = miEventQueue.tail, newtail;
+unsigned int oldtail = miEventQueue.tail;
+unsigned int newtail = oldtail;
EventListPtr evt;
intisMotion = 0;
intevlen;
@@ -184,7 +185,6 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
return;
}
stuck = 0;
-miEventQueue.tail = newtail;
}
evlen = sizeof(xEvent);
@@ -218,6 +218,7 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
miEventQueue.events[oldtail].pDev = pDev;
miEventQueue.lastMotion = isMotion;
+miEventQueue.tail = newtail;
}
Anyway this patch is not good enough. newtail is also deferenced (line
173) before his first usage, making the first hunk not utilized.
Thanks,
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg fails to start when using correct busids in device sections, logs included
Bill Crawford escreveu: Is anyone else currently working on this? It's fairly critical for anyone using multi-gpu systems (e.g. me, but I'm sure I can't be the only one). Yes, lately there's a lot of users complaining about this here in the list. I think no one is dealing with this right now. As always our lack of man power :( -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg fails to start when using correct busids in device sections, logs included
Jelle de Jong escreveu: Hello everybody, I am debugging some configuration problems i am encountering, so i made an simple test xorg.conf and attached the logs. When an busid is provided in the device section to try separate cards and/or heads xorg tells there is no matching device system for the busid that is provided while the logs say correct matching busids are used. Can somebody tell me what is going wrong here? I am experiencing the same issue with both the intel as radeonhd drivers. Any help is appreciated, http://lists.freedesktop.org/archives/xorg/2008-September/039020.html -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
--- a/hw/xfree86/loader/xf86sym.c
+++ b/hw/xfree86/loader/xf86sym.c
@@ -375,6 +375,8 @@ _X_HIDDEN void *xfree86LookupTab[] = {
SYMFUNC(SetTimeSinceLastInputEvent)
SYMFUNC(xf86AddInputHandler)
SYMFUNC(xf86RemoveInputHandler)
+SYMFUNC(xf86DisableInputHandler)
+SYMFUNC(xf86EnableInputHandler)
SYMFUNC(xf86AddEnabledDevice)
SYMFUNC(xf86RemoveEnabledDevice)
SYMFUNC(xf86InterceptSignals)
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master' - 2 commits
Aaron Plattner escreveu: As for the NVIDIA driver, you can use nm -D on it to see which symbols it's linked against. Also, I have a list of the strings we pass to LoaderSymbol at http://people.freedesktop.org/~aplattner/loadersymbol It was a bit out of date, so I updated it. disassemble the proprietary driver would not be illegal? -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg process takes too much time cpu
tirengarfio escreveu: I have observed, since some days, xorg process takes too much time cpu. I didn't touch anything at all at my computer or files. But im sure about this change... The last days I've been with a moderate fever. I didn't do anything wrong. But I'm sure about this change. Some can help me? Doctor can you help me? --- How can someone prescribe a receipt without know the symptoms of the system? Or in other words: send the log file and try to be precisely when doing questions :) -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 2/4] X event queue mutex
Simon Thum escreveu: Keith Packard wrote: Why does inserting events do anything but pull events from the kernel, insert them to the queue and update the sprite location on the screen? All event processing should happen in the main server thread; the only latency we're looking to reduce is the mouse-sprite update. It's really not much: Middle button emu, translation/acceleration, ... The point being their guts are exposed via input properties. Most cases are trivial, which reads 'fairly safe given properly aligned writes are atomic'. For the rest, there should be provisions (like suppressing input processing) or a clear statement against complicated stuff in props. At least, that's my opinion. (Just to note: my last patch totally ignores the eventual races issues with input thread and input device properties) Sh*t, the things are starting to get confused again. Keith was right saying that the IT needs only to worry with sprite updates, and we're _not_ doing this right now. The input thread covers all the input event generation stage and more other bits. A problem that I see is in GetPointerEvents() function. It's bloated and confusing. It generates X events and also updates the cursor on screen. We don't need to mix this two actions in one function. For instance, I did a quickly hack here calling miPointerSetPosition() directly from evdev driver (!) instead inside GPE and apparently all worked nice. So if we could only put in a separate thread the pieces that deal with cursor's update and not related with X events then we'd be winning -- I failed to not see this before :( On the other hand, if we're moving to the kernel the pieces of our stack which are close with hw interaction, then it'd be more logical to move also all this not-window-related stuff to the kernel (inside drm, etc) and forget the input thread for all eternity. So yeah, I have to think a little more about this all. I think I still have a breath to start adventure again in kernel side. Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 0/4] X server's input thread (resending)
Hi, Here attached are the patches against the server to separate its input generation code in another thread. The main difference in this second try is the hook to put hotplug devices to work and the pthread consistency in all code. configure.ac |8 + dix/main.c | 11 + hw/xfree86/common/xf86Events.c | 21 +++ include/dix-config.h.in|3 include/opaque.h |3 include/os.h | 17 ++ mi/mieq.c | 55 os/Makefile.am |7 - os/WaitFor.c |8 + os/connection.c| 55 +++- os/inputthread.c | 280 + 11 files changed, 466 insertions(+), 2 deletions(-) Thanks, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/4] The input thread core file implementation
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
From 856d2e3906a9a3f1ea55249f43e1ea1310f22d2d Mon Sep 17 00:00:00 2001
From: Tiago Vignatti [EMAIL PROTECTED]
Date: Wed, 1 Oct 2008 21:13:26 -0300
Subject: [PATCH] The input-thread core file implementation.
Signed-off-by: Tiago Vignatti [EMAIL PROTECTED]
---
os/inputthread.c | 280 ++
1 files changed, 280 insertions(+), 0 deletions(-)
create mode 100644 os/inputthread.c
diff --git a/os/inputthread.c b/os/inputthread.c
new file mode 100644
index 000..e2eb15f
--- /dev/null
+++ b/os/inputthread.c
@@ -0,0 +1,280 @@
+/* inputthread.c -- The input thread implementation.
+ *
+ * Copyright 2007-2008 Tiago Vignatti [EMAIL PROTECTED]
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Except as contained in this notice, the name of the copyright holder(s)
+ * and author(s) shall not be used in advertising or otherwise to promote
+ * the sale, use or other dealings in this Software without prior written
+ * authorization from the copyright holder(s) and author(s).
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+
+#include pthread.h
+#include signal.h
+#include errno.h
+#include X11/Xpoll.h
+
+#include inputstr.h
+#include opaque.h
+
+
+static int WaitForInput(void* argument);
+
+typedef struct _InputDeviceFunc {
+void(*f) (void *);
+int fd;
+void*closure;
+} InputDeviceFunc;
+
+InputDeviceFuncDevFunc[MAX_DEVICES];
+
+fd_set InputThreadFd; /* Devices monitored by the input thread */
+int MainThreadReadPipe = -1;
+int MainThreadWritePipe = -1;
+int InputThreadReadPipe = -1;
+int InputThreadWritePipe = -1;
+
+pthread_t tid_input;
+
+
+void
+InitInputThread(void)
+{
+int i, main_to_input[2], input_to_main[2];
+
+/* The communication channel between the input and main thread in
+ * both ways.*/
+if (pipe(main_to_input) 0) {
+perror(pipe);
+exit(1);
+}
+if (pipe(input_to_main) 0) {
+perror(pipe);
+exit(1);
+}
+
+/* Make the pipes nonblocking */
+fcntl(main_to_input[0], F_SETFL, O_NONBLOCK);
+fcntl(main_to_input[1], F_SETFL, O_NONBLOCK);
+fcntl(input_to_main[0], F_SETFL, O_NONBLOCK);
+fcntl(input_to_main[1], F_SETFL, O_NONBLOCK);
+
+MainThreadReadPipe = main_to_input[0];
+MainThreadWritePipe = main_to_input[1];
+InputThreadReadPipe = input_to_main[0];
+InputThreadWritePipe = input_to_main[1];
+
+
+FD_ZERO(InputThreadFd);
+
+for (i = 0; i MAX_DEVICES; i++)
+DevFunc[i].fd = 0;
+}
+
+/*
+ * Called by the dix to create the input thread.
+ */
+void
+CreateInputThread (void)
+{
+pthread_t input_thread;
+pthread_attr_t attr;
+
+pthread_attr_init(attr);
+
+/* In OSes that differentiates processes and threads this could have some
+ * sense. Linux uses 1:1 thread model. The scheduler handles every thread
+ * as if it were a process. Therefore this bellow have no meaning if your
+ * OS is Linux.
+ */
+if (pthread_attr_setscope(attr, PTHREAD_SCOPE_SYSTEM) != 0)
+perror(error setting input thread scope);
+
+if (pthread_attr_setstacksize(attr, PTHREAD_STACK_MIN) != 0)
+perror(error setting input thread stack size);
+
+pthread_create(input_thread, attr, (void *)WaitForInput, NULL);
+pthread_attr_destroy (attr);
+}
+
+/*
+ * Called by the dix to close the input thread cleanly.
+ *
+ * TODO: This is a blinded implementation due X server regenaration
+ * is currently broken.
+ */
+void
+CloseInputThread (void)
+{
+RemoveEnabledDevice(MainThreadReadPipe);
+FD_ZERO(InputThreadFd);
+
+pthread_kill(tid_input, SIGKILL);
+}
+
+/*
+ * Create connections in the input thread. Must be called by the
+ * DDX implementation.
+ */
+void
+AddEnabledDeviceThreaded(int fd, void (*f)(void *), void *closure)
+{
+int i
[PATCH 2/4] X event queue mutex
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
From 6e0692f6a5757b6d838d857bdb68596a5208c6e2 Mon Sep 17 00:00:00 2001
From: Tiago Vignatti [EMAIL PROTECTED]
Date: Wed, 1 Oct 2008 21:15:15 -0300
Subject: [PATCH] X event queue mutex.
A mutex is needed because the X event queue is a critical region. Though
the X event queue is re-entrant, we cannot guarantee the simultaneous
processing by both main and input threads.
Signed-off-by: Tiago Vignatti [EMAIL PROTECTED]
---
mi/mieq.c | 55 +++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/mi/mieq.c b/mi/mieq.c
index 0a1b740..f9f9d8f 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
@@ -53,6 +53,10 @@ in this Software without prior written authorization from The Open Group.
# include extinit.h
# include exglobals.h
+#ifdef INPUT_THREAD
+#include pthread.h
+#endif
+
#ifdef DPMSExtension
# include dpmsproc.h
# define DPMS_SERVER
@@ -81,6 +85,13 @@ typedef struct _EventQueue {
static EventQueueRec miEventQueue;
+#ifdef INPUT_THREAD
+/* We need mutex because the X event queue is a critical region.
+Though the X event queue is re-entrant, we cannot guarantee the
+simultaneous processing by both main and input threads. */
+pthread_mutex_t miEventQueueMutex = PTHREAD_MUTEX_INITIALIZER;
+#endif
+
Bool
mieqInit(void)
{
@@ -122,6 +133,9 @@ mieqResizeEvents(int min_size)
void
mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
{
+#ifdef INPUT_THREAD
+pthread_mutex_lock(miEventQueueMutex);
+#endif
unsigned int oldtail = miEventQueue.tail, newtail;
EventListPtr evt;
intisMotion = 0;
@@ -146,6 +160,9 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
if (laste-nevents 6) {
ErrorF([mi] mieqEnqueue: more than six valuator events; dropping.\n);
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
return;
}
if (oldtail == miEventQueue.head ||
@@ -157,10 +174,16 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
((lastkbp-deviceid DEVICE_BITS) !=
(v-deviceid DEVICE_BITS))) {
ErrorF([mi] mieqEnequeue: out-of-order valuator event; dropping.\n);
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
return;
}
memcpy((laste-events[laste-nevents++].event), e, sizeof(xEvent));
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
return;
}
@@ -176,6 +199,9 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
if (newtail == miEventQueue.head) {
ErrorF([mi] EQ overflowing. The server is probably stuck
in an infinite loop.\n);
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
return;
}
miEventQueue.tail = newtail;
@@ -193,6 +219,9 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
if (!evt-event)
{
ErrorF([mi] Running out of memory. Tossing event.\n);
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
return;
}
}
@@ -212,24 +241,43 @@ mieqEnqueue(DeviceIntPtr pDev, xEvent *e)
miEventQueue.events[oldtail].pDev = pDev;
miEventQueue.lastMotion = isMotion;
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
}
void
mieqSwitchScreen(DeviceIntPtr pDev, ScreenPtr pScreen, Bool fromDIX)
{
+#ifdef INPUT_THREAD
+pthread_mutex_lock(miEventQueueMutex);
+#endif
+
EnqueueScreen(pDev) = pScreen;
if (fromDIX)
DequeueScreen(pDev) = pScreen;
+
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
}
void
mieqSetHandler(int event, mieqHandler handler)
{
+#ifdef INPUT_THREAD
+pthread_mutex_lock(miEventQueueMutex);
+#endif
+
if (handler miEventQueue.handlers[event])
ErrorF([mi] mieq: warning: overriding existing handler %p with %p for
event %d\n, miEventQueue.handlers[event], handler, event);
miEventQueue.handlers[event] = handler;
+
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
}
/**
@@ -304,6 +352,10 @@ mieqProcessInputEvents(void)
xEvent* event,
*master_event = NULL;
+#ifdef INPUT_THREAD
+pthread_mutex_lock(miEventQueueMutex);
+#endif
+
while (miEventQueue.head != miEventQueue.tail) {
if (screenIsSaved == SCREEN_SAVER_ON)
dixSaveScreens (serverClient, SCREEN_SAVER_OFF, ScreenSaverReset);
@@ -390,5 +442,8 @@ mieqProcessInputEvents(void)
miPointerUpdateSprite(e-pDev);
}
}
+#ifdef INPUT_THREAD
+pthread_mutex_unlock(miEventQueueMutex);
+#endif
}
--
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Bus types other than PCI not yet isolable
Hugo Vanwoerkom escreveu: I run a 2-seater (2 videocards/servers/mice/keyboards/monitors) on Debian Sid. That works successfully with xorg 1:7.2-5 (that's Debian's designation). So that's an installation that has not been upgraded recently. Under the recent upgrades with xorg 1:7.3+10 that doesn't work anymore and I get 'Bus types other than PCI not yet isolable'. The relevant isolatedevice's are: command=/usr/bin/X1 :0 -layout X1 -dpi 110 -deferglyphs 16 -isolateDevice \PCI:1:0:0\ vt7 command=/usr/bin/X0 :1 -layout X0 -dpi 110 -deferglyphs 16 -isolateDevice \PCI:0:8:0\ -sharevts Can anybody shed light on the reason for that error message that now appears but used to work OK? (I'm not sure what version of Xorg is in Debian Sid but I presume is 7.4 or newer) Since Xorg started to use libpciaccess (introduced in 7.4), we don't build a method to post secondary cards on server. Sigh. I'll try to adventure on this issue soon -- after my other pending work [0]. Cheers, [0] server's input threadification. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Jason Spiro escreveu: Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. The DontZap option in xorg.conf isn't enough for you? `man 5 xorg.conf` Cheers, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
