[ANNOUNCE] xorg-server 1.12.2.902
== Description == This is the second release candidate for 1.12.3. A few input changes, avoiding messing up the event queue on some RandR events. A warning is now printed to the log if SlowKeys is turned on. Update on the schedule: This RC should've been released on Friday but I ran out of time and didn't get to it on the weekend either. So I've moved the 1.12.3 release date back, it will 7 days from now, next monday. == Known Issues == Currently open bugs the 1.12 Tracker: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 23938: keys occasionally get stuck with xorg-server 1.6.99.901 http://bugs.freedesktop.org/23938 31501: crash accessing font info with xfs in fontpath http://bugs.freedesktop.org/31501 39094: WaitFor does not handle EIO (causes 100% cpu load) http://bugs.freedesktop.org/39094 39383: X server crashes when restarting KDE from Alt+F2 http://bugs.freedesktop.org/39383 39949: RandR panning & scaling don't work http://bugs.freedesktop.org/39949 43988: crtc->desiredMode.name can point to freed memory. http://bugs.freedesktop.org/43988 44038: some 3D wine apps no longer work (bisected) http://bugs.freedesktop.org/44038 45445: Key press crashes the xserver when kdm is running http://bugs.freedesktop.org/45445 49170: crash when starting or after some time of using psi http://bugs.freedesktop.org/49170 50641: xorg-server-1.12.0 - When SELinux is enabled the xserver fails http://bugs.freedesktop.org/50641 50683: Black screen with "AutoAddDevices" "Off" http://bugs.freedesktop.org/50683 == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server112Branch == Changes since 1.12.1.902 == Andy Ritger (1): randr: Don't recurse into mieqProcessInputEvents() from RRTellChanged(). Peter Hutterer (4): xkb: warn if XKB SlowKeys have been automatically enabled Xi: fix XITouchClass sourceid assignment dix: if the scroll valuator reaches INT_MAX, reset to 0 configure.ac: Version bump to 1.12.2.902 (1.12.3 RC2) git tag: xorg-server-1.12.2.902 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.902.tar.bz2 MD5: 74175b023bdd46244c1ba6c50735c011 xorg-server-1.12.2.902.tar.bz2 SHA1: ad084777de751076f9459e5e6e5485f504992638 xorg-server-1.12.2.902.tar.bz2 SHA256: 3de52fb923aed147c03d0ef6f5c5f0cf7a0bd57bac860bae66d636fcfa0031a6 xorg-server-1.12.2.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.2.902.tar.gz MD5: 8abe6384130238546623e32edd92ecbf xorg-server-1.12.2.902.tar.gz SHA1: e43b8891bfd8ad5238223a92c71340bba88fc3c7 xorg-server-1.12.2.902.tar.gz SHA256: 7cc971895d7c03bbc189016771dfbe16d1ca3303ea1ef17215f38d0513a52036 xorg-server-1.12.2.902.tar.gz pgp17fhBVBoKG.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH v3] x86emu: Correctly handle 0x66 prefix for some instructions
I repost this patch because I havn't got any replies from maintainers
since I posted the initial patch back in March.
Some instructions are not emulated correctly by x86emu when they
are prefixed by the 0x66 opcode.
I've identified problems in the emulation of these intructions: ret,
enter, leave, iret and some forms of call.
Most of the time, the problem is that these instructions should push or
pop 32-bit values to/from the stack, instead of 16bit, when they are
prefixed by the 0x66 special opcode.
The SeaBIOS project aims to produce a complete legacy BIOS
implementation as well as a VGA option ROM, entirely written in C and
using the GCC compiler.
In 16bit code produced by the GCC compiler, the 0x66 prefix is used
almost everywhere. This patch is necessary to allow the SeaBIOS VGA
option ROM to function with Xorg when using the vesa driver.
SeaBIOS currently use postprocessing on the ROM assembly output to
replace the affected instruction with alternative unaffected instructions.
This is obviously not very elegant, and this fix in x86emu would be
more appropriate.
v2: - Decrement BP instead of EBP in accordance with the Intel Manual
- Assign EIP instead of IP when poping the return address from the
stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret
- When poping EFLAGS from the stack in iret in 32-bit operand size
mode, apply some mask to preserve Read-only flags.
v3: - Rebase
Signed-off-by: Julian Pidancet
---
hw/xfree86/x86emu/ops.c | 192 ++
1 files changed, 142 insertions(+), 50 deletions(-)
diff --git a/hw/xfree86/x86emu/ops.c b/hw/xfree86/x86emu/ops.c
index 76b8358..d4a4caf 100644
--- a/hw/xfree86/x86emu/ops.c
+++ b/hw/xfree86/x86emu/ops.c
@@ -8949,7 +8949,11 @@ x86emuOp_ret_near_IMM(u8 X86EMU_UNUSED(op1))
DECODE_PRINTF2("%x\n", imm);
RETURN_TRACE("RET", M.x86.saved_cs, M.x86.saved_ip);
TRACE_AND_STEP();
-M.x86.R_IP = pop_word();
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_EIP = pop_long();
+} else {
+M.x86.R_IP = pop_word();
+}
M.x86.R_SP += imm;
DECODE_CLEAR_SEGOVR();
END_OF_INSTR();
@@ -8966,7 +8970,11 @@ x86emuOp_ret_near(u8 X86EMU_UNUSED(op1))
DECODE_PRINTF("RET\n");
RETURN_TRACE("RET", M.x86.saved_cs, M.x86.saved_ip);
TRACE_AND_STEP();
-M.x86.R_IP = pop_word();
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_EIP = pop_long();
+} else {
+M.x86.R_IP = pop_word();
+}
DECODE_CLEAR_SEGOVR();
END_OF_INSTR();
}
@@ -9259,8 +9267,13 @@ x86emuOp_enter(u8 X86EMU_UNUSED(op1))
frame_pointer = M.x86.R_SP;
if (nesting > 0) {
for (i = 1; i < nesting; i++) {
-M.x86.R_BP -= 2;
-push_word(fetch_data_word_abs(M.x86.R_SS, M.x86.R_BP));
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_BP -= 4;
+push_long(fetch_data_long_abs(M.x86.R_SS, M.x86.R_BP));
+} else {
+M.x86.R_BP -= 2;
+push_word(fetch_data_word_abs(M.x86.R_SS, M.x86.R_BP));
+}
}
push_word(frame_pointer);
}
@@ -9281,7 +9294,11 @@ x86emuOp_leave(u8 X86EMU_UNUSED(op1))
DECODE_PRINTF("LEAVE\n");
TRACE_AND_STEP();
M.x86.R_SP = M.x86.R_BP;
-M.x86.R_BP = pop_word();
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_EBP = pop_long();
+} else {
+M.x86.R_BP = pop_word();
+}
DECODE_CLEAR_SEGOVR();
END_OF_INSTR();
}
@@ -9301,8 +9318,13 @@ x86emuOp_ret_far_IMM(u8 X86EMU_UNUSED(op1))
DECODE_PRINTF2("%x\n", imm);
RETURN_TRACE("RETF", M.x86.saved_cs, M.x86.saved_ip);
TRACE_AND_STEP();
-M.x86.R_IP = pop_word();
-M.x86.R_CS = pop_word();
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_EIP = pop_long();
+M.x86.R_CS = pop_long() & 0x;
+} else {
+M.x86.R_IP = pop_word();
+M.x86.R_CS = pop_word();
+}
M.x86.R_SP += imm;
DECODE_CLEAR_SEGOVR();
END_OF_INSTR();
@@ -9319,8 +9341,13 @@ x86emuOp_ret_far(u8 X86EMU_UNUSED(op1))
DECODE_PRINTF("RETF\n");
RETURN_TRACE("RETF", M.x86.saved_cs, M.x86.saved_ip);
TRACE_AND_STEP();
-M.x86.R_IP = pop_word();
-M.x86.R_CS = pop_word();
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_EIP = pop_long();
+M.x86.R_CS = pop_long() & 0x;
+} else {
+M.x86.R_IP = pop_word();
+M.x86.R_CS = pop_word();
+}
DECODE_CLEAR_SEGOVR();
END_OF_INSTR();
}
@@ -9421,9 +9448,15 @@ x86emuOp_iret(u8 X86EMU_UNUSED(op1))
TRACE_AND_STEP();
-M.x86.R_IP = pop_word();
-M.x86.R_CS = pop_word();
-M.x86.R_FLG = pop_word();
+if (M.x86.mode & SYSMODE_PREFIX_DATA) {
+M.x86.R_EIP = pop_long();
+M.x86.R_CS = pop_long() & 0x;
+M.x86.R_EFLG = (pop_long() & 0x257FD5) | (M.x86.R_EFLG & 0x1A);
+} else {
+M.x86.R_IP = pop
Re: [ANNOUNCE] pixman release 0.26.2 now available
On Sun, Jul 1, 2012 at 5:09 AM, Somchai Smythe wrote: > Are you sure about those hash values? They do not work for me. I > tried both md5sum and sha1sum for pixman-0.26.2.tar.gz They're wrong -- not sure why or how. The correct values are 6b3e4c5300adb893a2baa9631c23efb2 pixman-0.26.2.tar.bz2 276242da5b3af1258d072cf205d18f0b pixman-0.26.2.tar.gz ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: newbie resource temporarily unavailable
pk wrote: > > FYI > > perhaps this is correct for desktop but there are several applications > > in the wild that are used regular that require Xt. That's the difference between "legacy" and "obsolete". Legacy software still has some value due to historical (i.e. compatibility) reasons, but wouldn't normally be considered if you were starting from a blank slate. If absolutely nothing used it, it would be "obsolete". > Besides XEmacs, regular Emacs (with X support), Gnu gv, Libreoffice, > Sun/Oracle JDK (with X support), tk, Thunderbird, Imagemagick (with X > support), Firefox, Seamonkey, Xscreensaver, Xterm amongst others all > depends on Xt acc. to my 'equery depends x11-libs/libXt' on my Gentoo > machine (not sure if all is runtime dependencies though). So it seems Xt > is far from dead? Firefox only uses Xt because it's specified by the Netscape plug-in API, which dates back to when Netscape Navigator used Motif. It was re-written using GTK shortly after it became Free software due to Motif being non-Free and the free alternative (Lesstif) being insufficiently robust. Tk isn't linked against libXt, but it might need some files which are part of the libXt package (Tk uses X resources, but does so by manually parsing ~/.Xdefaults etc; it doesn't even use the Xrm* functions from Xlib). The ImageMagick libraries are linked against libXt, but don't appear to use any symbols from it. It uses libdl, so it's possible that, like Firefox, there are third-party plug-ins which depend upon Xt. Many others are themselves bordering on legacy status (e.g. Gnome and KDE each have their own terminal emulators). -- Glynn Clements ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] pixman release 0.26.2 now available
Are you sure about those hash values? They do not work for me. I tried both md5sum and sha1sum for pixman-0.26.2.tar.gz On 6/30/12, Matt Turner wrote: > A new pixman release 0.26.2 is now available. This is a stable release. It > contains some bug fixes, custom build rules for ARM/iwMMXt, and an > important > bug fix for MMX/x86. > > tar.gz: > http://cairographics.org/releases/pixman-0.26.2.tar.gz > http://xorg.freedesktop.org/archive/individual/lib/pixman-0.26.2.tar.gz > > tar.bz2: > http://xorg.freedesktop.org/archive/individual/lib/pixman-0.26.2.tar.bz2 > > Hashes: > MD5: 69af3cf4ce6515ee01b0960edf8009fb pixman-0.26.2.tar.gz > MD5: 2b57fb3038be4890ec433d11176280cd pixman-0.26.2.tar.bz2 > SHA1: ba71d029d174aa8b9d23b1072ab76e6b4ea3de59 pixman-0.26.2.tar.gz > SHA1: c7cdb5803061ee6614acc66258b0339ad4e52314 pixman-0.26.2.tar.bz2 > > GPG signature: > http://cairographics.org/releases/pixman-0.26.2.tar.gz.sha1.asc > (signed by Matt Turner ) > > Git: > git://git.freedesktop.org/git/pixman > tag: pixman-0.26.2 > > Log: > Matt Turner (6): > Post-release version bump to 0.26.1 > mmx: add missing _mm_empty calls > autotools: use custom build rule to build iwMMXt code > configure.ac: add iwmmxt2 configure flag > Fix distcheck due to custom iwMMXt rules > Pre-release version bump to 0.26.2 > > Siarhei Siamashka (2): > test: OpenMP 2.5 requires signed loop iteration variables > test: fix bisecting issue in fuzzer-find-diff.pl > > Søren Sandmann Pedersen (1): > test: Add missing break in stress-test.c > > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: newbie resource temporarily unavailable
On 2012-07-01 10:54, walter harms wrote: > FYI > perhaps this is correct for desktop but there are several applications > in the wild that are used regular that require Xt. Besides XEmacs, regular Emacs (with X support), Gnu gv, Libreoffice, Sun/Oracle JDK (with X support), tk, Thunderbird, Imagemagick (with X support), Firefox, Seamonkey, Xscreensaver, Xterm amongst others all depends on Xt acc. to my 'equery depends x11-libs/libXt' on my Gentoo machine (not sure if all is runtime dependencies though). So it seems Xt is far from dead? Best regards Peter K ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: newbie resource temporarily unavailable
Am 30.06.2012 15:31, schrieb Glynn Clements: > > Alan Corey wrote: > >> Well, you see, I just really dislike C++. I've tried on and off for >> years and I just can't get it through my head. I want a toolkit I can >> program in C. FLTK seems great, same with GTK, but not without C++. >> I'm familiar with OO programming concepts from Java, Delphi and Perl >> but C++? Uh-uh. > > I would have thought that GTK would fit the bill. > >>> I wouldn't advise putting too much effort into Xt/Xaw stuff; they've >>> fallen so far into disuse that if X.org shipped a totally >>> non-functional version of one of those libraries, it might take a year >>> before anyone actually noticed. >> >> Wouldn't that break a bunch of things that rely on them? > > Such as? The typical Linux desktop environment doesn't have any > Xt-based applications; Gnome uses GTK and KDE uses Qt. > > Okay, Xt isn't quite dead yet (e.g. XEmacs (which I'm using at this > moment) requires it), but it's quite definitely "legacy" at this > point. > FYI perhaps this is correct for desktop but there are several applications in the wild that are used regular that require Xt. re, wh ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
