Re: [PATCH] Add a return value to load_cursor_argb() to allow it to report failure
Hello Dave, On 04/04/14 01:21, Dave Airlie wrote: load_cursor_argb() may need to be able to fail and have the server fall back to a software cursor in at least the following circumstances. 1) The hardware can only support some ARGB cursors and this does not just depend on cursor size. 2) Virtual hardware may not wish to pass through a cursor to the host at a particular time but may wish to accept the same cursor at another time. This patch adds a return value to the API and makes the server do the software fall-back on failure. Signed-off-by: Michael Thayer michael.tha...@oracle.com I think this is a welcome ABI break, and I probably should have done something like it ages ago when doing -modesetting, Reviewed-by: Dave Airlie airl...@redhat.com Thanks for the review! Does X.Org custom say that I should sent patches (which I obviously can't test) for all or some of the public drivers, or that the driver maintainers should do that? And my question about whether a similar patch for set_cursor_position() would make sense is still open (I assume this is relevant for Qemu too): VirtualBox can use the host cursor as a hardware cursor for a guest system, but it can't change its position, so if the guest wants the cursor anywhere except where the host put it (e.g. another device controlling it, or the cursor confined to a screen region) it needs to draw it itself. Of course, set_cursor_position() should still be called even after it has failed once so that we could switch back if the positions matched again. Regards, Michael -- ORACLE Deutschland B.V. Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] os: Initialize the set of signals to be suppressed during our handler.
Fixes a valgrind complaint: ==8805== Syscall param rt_sigaction(act-sa_mask) points to uninitialised byte(s) ==8805==at 0x5EB8315: __libc_sigaction (sigaction.c:66) ==8805==by 0x5B13DA: busfault_init (busfault.c:145) ==8805==by 0x5A60A2: OsInit (osinit.c:191) ==8805==by 0x46EBA2: dix_main (main.c:163) Signed-off-by: Eric Anholt e...@anholt.net --- os/busfault.c | 1 + 1 file changed, 1 insertion(+) diff --git a/os/busfault.c b/os/busfault.c index 43bb6ea..ac0268f 100644 --- a/os/busfault.c +++ b/os/busfault.c @@ -142,6 +142,7 @@ busfault_init(void) act.sa_sigaction = busfault_sigaction; act.sa_flags = SA_SIGINFO; +sigemptyset(act.sa_mask); if (sigaction(SIGBUS, act, old_act) 0) return FALSE; previous_busfault_sigaction = old_act.sa_sigaction; -- 1.9.1 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?
Perhaps those two little fixes I sent yesterday to get things building on ARM again (with default config): default to stub int10 implementation on arm int10: fix build error BR, -R On Thu, Apr 3, 2014 at 10:49 PM, Matt Dew mar...@osource.org wrote: Hey folks, Any body have any thing more for xserver stable? Either 1.15.1 or 1.14.6? Current plan is one week from today for releases. Matt -- Matt Dew mar...@osource.org Key signature: 0xF7C3 BEC3 Fingerprint: FDB1 9D94 C573 DC29 BCCB 2F9F A6BF 3771 F7C3 BEC3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
xauth warning: WRITES macro
Hi!
clang doesn't like the WRITES macro xauth uses:
process.c:867:3: warning: if statement has empty body [-Wempty-body]
WRITES(STDERR_FILENO, \n);
^
process.c:641:57: note: expanded from macro 'WRITES'
#define WRITES(fd, S) {if(write((fd), (S), strlen((S;}
^
process.c:867:3: note: put the semicolon on a separate line to silence this
warning
process.c:641:57: note: expanded from macro 'WRITES'
#define WRITES(fd, S) {if(write((fd), (S), strlen((S;}
Why is there an empty if, anyway?
Thomas
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?
On Thu, Apr 3, 2014 at 20:49:53 -0600, Matt Dew wrote: Hey folks, Any body have any thing more for xserver stable? Either 1.15.1 or 1.14.6? I requested a cherry-pick in http://lists.x.org/pipermail/xorg-devel/2014-March/041572.html but didn't get a reply from you. Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH RESEND2 xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. The test directory needs source from hw/xfree86 which is neither under test nor under a sub directory of test. In 1.14 we get a warning, in 2.0 it will break as it will overwrite the object code in xfree86. The solution in this case is to create a link to hw/xfree86/sdksyms.c at build time. It's just like any other built source file. There are no links created in git. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/.gitignore |1 + test/Makefile.am |8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/test/.gitignore b/test/.gitignore index acbda7a..da86d6e 100644 --- a/test/.gitignore +++ b/test/.gitignore @@ -4,6 +4,7 @@ input list misc os +sdksyms.c string touch xfree86 diff --git a/test/Makefile.am b/test/Makefile.am index 2852bb3..afd8866 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -42,7 +42,7 @@ os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) if XORG -nodist_libxservertest_la_SOURCES = $(top_builddir)/hw/xfree86/sdksyms.c +nodist_libxservertest_la_SOURCES = sdksyms.c libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/loader/libloader.la \ $(top_builddir)/hw/xfree86/os-support/libxorgos.la \ @@ -56,6 +56,12 @@ libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/dixmods/libxorgxkb.la \ @XORG_LIBS@ +BUILT_SOURCES = sdksyms.c +CLEANFILES = sdksyms.c + +sdksyms.c: $(top_builddir)/hw/xfree86/sdksyms.c + $(AM_V_GEN)$(LN_S) $(top_builddir)/hw/xfree86/sdksyms.c + if DRI libxservertest_la_LIBADD += $(top_builddir)/hw/xfree86/dri/libdri.la endif -- 1.7.9.5 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add a return value to load_cursor_argb() to allow it to report failure
On 04/04/14 20:46, Jasper St. Pierre wrote: For qemu, this is handled at the kernel modesetting level with QXL. See drmModeSetCursor2. On Fri, Apr 4, 2014 at 3:30 AM, Michael Thayer michael.tha...@oracle.com mailto:michael.tha...@oracle.com wrote: And my question about whether a similar patch for set_cursor_position() would make sense is still open (I assume this is relevant for Qemu too): VirtualBox can use the host cursor as a hardware cursor for a guest system, but it can't change its position, so if the guest wants the cursor anywhere except where the host put it (e.g. another device controlling it, or the cursor confined to a screen region) it needs to draw it itself. Of course, set_cursor_position() should still be called even after it has failed once so that we could switch back if the positions matched again. Isn't drmModeSetCursor2() for passing through the hot-spot? I'm not sure this would help if the X server wanted to put the cursor in a different location to the host pointer, particularly if it didn't change the sprite at that time since then drmModeSetCursor2() would not get called. Regards, Michael -- ORACLE Deutschland B.V. Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xinit v3 3/3] startx: Under Linux start X on the current VT
On 04/04/14 05:39 AM, Peter Hutterer wrote: On Mon, Mar 31, 2014 at 03:51:46PM +0200, Hans de Goede wrote: When we let X allocate a new VT, systemd-logind will not recognize any processes running on this VT as belonging to a valid session (since there was no pam session opened on that tty). This causes problems like PolicyKit denials for these processes. ConsoleKit under Linux has been deprecated for a few years now and is no longer being maintained, so simply make this the default under Linux. Note we do not pass in the vt if the user has specified an alternative server to start, as the vtX argument is only valid for the Xorg server, likewise we omit it if the user has specified any other server arguments. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=806491 Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Peter Hutterer peter.hutte...@who-t.net So this would cause an unrelated option like -nolisten tcp to change the VT on which X runs? I think this violates the principle of least surprise. I would prefer a patch that checks if X is setuid root. If so, use VT7 because that's what everyone is used to. If not, use the current VT. signature.asc Description: OpenPGP digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xauth warning: WRITES macro
On 04/ 4/14 05:35 AM, Thomas Klausner wrote:
Hi!
clang doesn't like the WRITES macro xauth uses:
process.c:867:3: warning: if statement has empty body [-Wempty-body]
WRITES(STDERR_FILENO, \n);
^
process.c:641:57: note: expanded from macro 'WRITES'
#define WRITES(fd, S) {if(write((fd), (S), strlen((S;}
^
process.c:867:3: note: put the semicolon on a separate line to silence this
warning
process.c:641:57: note: expanded from macro 'WRITES'
#define WRITES(fd, S) {if(write((fd), (S), strlen((S;}
Why is there an empty if, anyway?
Looks like it was done to shut up a different compiler warning:
http://cgit.freedesktop.org/xorg/app/xauth/commit/?id=afeb2c22ba1f7193acf814954e66f40cfd699c17
--
-Alan Coopersmith- alan.coopersm...@oracle.com
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xinit v2 3/3] startx: Under Linux start X on the current VT
On Thu, Mar 27, 2014 at 14:18:14 +0100, Mark Kettenis wrote: What you're basically saying is that on a modern Linux systems, the historic behaviour where X allocates a new VT and occupies it is no longer wanted. This raises several questions: 1. Is there consensus among the various Linux distros that this really is the desired default behaviour? I think it's going to surprise people. I'm certainly used to being able to switch back to the console after running startx. Now maybe it's not as big a deal as I fear, and we'll get used to the new behaviour, but I don't even know what the upside is... Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
