libdrm 2.4.1
New libdrm release to fix the symbol name collision between Mesa 7.2 and libdrm_intel. Also includes a fix for deadlock in non-GEM 2D, and support for aperture size checking in GEM. eaaaf08726d5ac6f3a7f20bf5ec0a013772d7b55 libdrm-2.4.1.tar.bz2 583c1c62f70877ec592245ca0316375662eeb693 libdrm-2.4.1.tar.gz 05feb4c5a48f1f0870a7cbe7617d6cf7 libdrm-2.4.1.tar.bz2 cbcb796bbb3bf9079c4cb22c9d051772 libdrm-2.4.1.tar.gz Alex Deucher (2): radeon: fix some fallout from the busmaster disable cleanup radeon: fix error in busmaster enable logic Ben Skeggs (2): nv50: move context-related tables a separate header file nv50: symlink nv50_grctx.h to linux-core... Eric Anholt (3): intel: Add dri_bufmgr_check_aperture support for bufmgr_gem. intel: Rename dri_ and intel_ symbols to drm_intel_. libdrm 2.4.1. Keith Packard (1): intel: ioctl is not defined to return -errno Matthias Hopf (1): drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831) Pekka Paalanen (1): drm: missing init_mm symbol, compatibility fix Robert Noland (3): [FreeBSD] This check isn't correct and causes at least mga to lockup. [FreeBSD] We should use dev2unit() rather than minor() i915: Since FreeBSD doesn't have gem support yet, don't advertise it. Xiang, Haihao (2): intel: avoid deadlock in intel_bufmgr_fake. intel: Also total child_size of the target_bos. Partial fix #17964. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[PATCH] evdev: Add support for run-time calibration.
Some devices require run-time axis calibration. We can't change the min/max
ranges once we've initialised the valuator structs though, so in-driver
run-time calibration is required.
If the property is set, the driver scales from the calibrated range to the
values reported to the X server (which then may scale to screen coordinates).
If the property is not set (i.e. zero items) no scaling is performed.
---
include/evdev-properties.h |4 +++
man/evdev.man |5
src/evdev.c| 50
src/evdev.h|7 ++
4 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/include/evdev-properties.h b/include/evdev-properties.h
index 89f25f1..be4307b 100644
--- a/include/evdev-properties.h
+++ b/include/evdev-properties.h
@@ -58,4 +58,8 @@
/* CARD8 */
#define EVDEV_PROP_REOPEN Evdev Reopen Attempts
+/* Run-time calibration */
+/* CARD32, 4 values [minx, maxx, miny, maxy], or no values for unset */
+#define EVDEV_PROP_CALIBRATION Evdev Axis Calibration
+
#endif
diff --git a/man/evdev.man b/man/evdev.man
index 9d336fc..fc8a96a 100644
--- a/man/evdev.man
+++ b/man/evdev.man
@@ -186,6 +186,11 @@ value.
.TP 7
.BI Evdev Axis Inversion
2 boolean values (8 bit, 0 or 1), order X, Y. 1 inverts the axis.
+.BI Evdev Axis Calibration
+4 32-bit values, order min-x, max-x, min-y, max-y or 0 values to disable
+run-time axis calibration. This feature is required for devices that need to
+scale to a different coordinate system than originally reported to the X
+server, such as touchscreens that require run-time calibration.
.SH AUTHORS
Kristian Høgsberg.
diff --git a/src/evdev.c b/src/evdev.c
index 9ef2829..aa8a10d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -76,6 +76,7 @@
#define EVDEV_TOUCHPAD (1 4)
#define EVDEV_INITIALIZED (1 5) /* WheelInit etc. called already? */
#define EVDEV_TOUCHSCREEN (1 6)
+#define EVDEV_CALIBRATED (1 7) /* run-time calibrated? */
#define MIN_KEYCODE 8
#define GLYPHS_PER_KEY 2
@@ -107,6 +108,7 @@ static int EvdevSetProperty(DeviceIntPtr dev, Atom atom,
XIPropertyValuePtr val, BOOL checkonly);
static Atom prop_invert = 0;
static Atom prop_reopen = 0;
+static Atom prop_calibration = 0;
#endif
@@ -387,6 +389,17 @@ EvdevReadInput(InputInfoPtr pInfo)
int abs_x, abs_y;
abs_x = pEvdev-abs_x;
abs_y = pEvdev-abs_y;
+
+if (pEvdev-flags EVDEV_CALIBRATED)
+{
+abs_x = xf86ScaleAxis(abs_x,
+pEvdev-max_x, pEvdev-min_x,
+pEvdev-calibration.max_x, pEvdev-calibration.min_x);
+abs_y = xf86ScaleAxis(abs_y,
+pEvdev-max_y, pEvdev-min_y,
+pEvdev-calibration.max_y, pEvdev-calibration.min_y);
+}
+
if (pEvdev-invert_x)
abs_x = pEvdev-max_x - (abs_x - pEvdev-min_x);
if (pEvdev-invert_y)
@@ -1542,6 +1555,16 @@ EvdevInitProperty(DeviceIntPtr dev)
return;
XISetDevicePropertyDeletable(dev, prop_reopen, FALSE);
+
+
+prop_calibration = MakeAtom(EVDEV_PROP_CALIBRATION,
+strlen(EVDEV_PROP_CALIBRATION), TRUE);
+rc = XIChangeDeviceProperty(dev, prop_calibration, XA_INTEGER, 32,
+PropModeReplace, 0, NULL, FALSE);
+if (rc != Success)
+return;
+
+XISetDevicePropertyDeletable(dev, prop_calibration, FALSE);
}
static int
@@ -1570,6 +1593,33 @@ EvdevSetProperty(DeviceIntPtr dev, Atom atom,
XIPropertyValuePtr val,
if (!checkonly)
pEvdev-reopen_attempts = *((CARD8*)val-data);
+} else if (atom == prop_calibration)
+{
+if (val-format != 32 || val-type != XA_INTEGER)
+return BadMatch;
+if (val-size != 4 val-size != 0)
+return BadMatch;
+
+if (!checkonly)
+{
+if (val-size == 0)
+{
+pEvdev-flags = ~EVDEV_CALIBRATED;
+pEvdev-calibration.min_x = 0;
+pEvdev-calibration.max_x = 0;
+pEvdev-calibration.min_y = 0;
+pEvdev-calibration.max_y = 0;
+} else if (val-size == 4)
+{
+CARD32 *vals = (CARD32*)val-data;
+
+pEvdev-flags |= EVDEV_CALIBRATED;
+pEvdev-calibration.min_x = vals[0];
+pEvdev-calibration.max_x = vals[1];
+pEvdev-calibration.min_y = vals[2];
+pEvdev-calibration.max_y = vals[3];
+}
+}
}
return Success;
diff --git a/src/evdev.h b/src/evdev.h
index 5a97185..5696978 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -102,6 +102,13 @@ typedef struct {
Timeexpires; /* time of expiry */
Timetimeout;
} emulateWheel;
+/* run-time calibration */
+struct {
+int
Re: Multi{pointer,touch} Userspace
In fact, all four daemons just expect classes derived from C++ iostream, so in the single-machine scenario, you could just put all of them into one multithreaded application and have them communicate internally. Heh. I don't think we'd ever accept a C++ library dependency for the X server. I wouldn't see such a library as part of the Xserver. I rather think that the Xserver should just supply pointer (and maybe later blob) events. The gesture recognizer itself would fit better into the freedesktop library set. After some quick investigation, I note that libxml2 is even more bloated than libxml1 was, weighing in at nearly 1.2 megabytes. expat is much lighter weighing in at 130K or so. We'll see There's also tinyxml [1], but that relies heavily on libstdc++. Yours, Florian [1] http://sourceforge.net/projects/tinyxml -- 0666 - Filemode of the Beast ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Cannot install fonts on FreeBSD due to a permission problem
Hello there, I have been building X-Server 1.5.1 on FreeBSD 7.0 and I've managed to build all prerequisites for X and X now tries to start, however at the end I realised that I had forgotten to install the fonts, but now when I try to install the fonts(any font for that matter), I get the error:- make install-data-hook PATHTOFONTS:Permission Denied Error code 1 Can someone please tell me what I am doing wrong here or be so kind as to point me in the right direction? Thanks in advance. Regards, Pramod Dematagoda ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Ansification of libICE
Please find attached a patch that makes libICE ANSI C compliant and fixes a
few small type related issues flagged by gcc and sparse.
Best Regards,
Magnus Kessler
Ansify libICE
Ansify libICE and fix some type issues flagged by sparse and gcc
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/ICElibint.h b/src/ICElibint.h
index ca61553..5880241 100644
--- a/src/ICElibint.h
+++ b/src/ICElibint.h
@@ -37,6 +37,7 @@ Author: Ralph Mor, X Consortium
#include X11/ICE/ICEproto.h
#include X11/ICE/ICEconn.h
#include X11/ICE/ICEmsg.h
+#include X11/ICE/ICEutil.h
#ifdef WIN32
#include X11/Xwindows.h
#endif
@@ -410,6 +411,9 @@ extern _IceWatchProc *_IceWatchProcs;
extern IceErrorHandler _IceErrorHandler;
extern IceIOErrorHandler _IceIOErrorHandler;
+extern int _IcePaAuthDataEntryCount;
+extern IceAuthDataEntry _IcePaAuthDataEntries[];
+
extern void _IceErrorBadMajor (
IceConn /* iceConn */,
@@ -537,4 +541,51 @@ extern void _IceGetPaValidAuthIndices (
int * /* indices_ret */
);
+extern void _IceDefaultErrorHandler (
+IceConn /* iceConn*/,
+Bool /* swap */,
+int /* offendingMinorOpcode */,
+unsigned long /* offendingSequence */,
+int /* errorClass */,
+int /* severity */,
+IcePointer /* values */
+);
+
+extern void _IceDefaultIOErrorHandler (
+IceConn /* iceConn */
+);
+
+extern IcePoAuthStatus _IcePoMagicCookie1Proc (
+IceConn /* iceConn */,
+IcePointer * /* authStatePtr */,
+Bool /* cleanUp */,
+Bool /* swap */,
+int /* authDataLen */,
+IcePointer /* authData */,
+int * /* replyDataLenRet */,
+IcePointer * /* replyDataRet */,
+char ** /* errorStringRet */
+);
+
+extern IcePaAuthStatus _IcePaMagicCookie1Proc(
+IceConn /* iceConn */,
+IcePointer * /* authStatePtr */,
+Bool /* swap */,
+int /* authDataLen */,
+IcePointer /* authData */,
+int * /* replyDataLenRet */,
+IcePointer * /* replyDataRet */,
+char ** /* errorStringRet */
+);
+
+extern void _IceProcessCoreMessage(
+IceConn /* iceConn */,
+int /* opcode */,
+unsigned long /* length */,
+Bool /* swap */,
+IceReplyWaitInfo * /* replyWait */,
+Bool * /* replyReadyRet */,
+Bool * /* connectionClosedRet */
+);
+
#endif /* _ICELIBINT_H_ */
diff --git a/src/accept.c b/src/accept.c
index d54ffd4..e883029 100644
--- a/src/accept.c
+++ b/src/accept.c
@@ -36,11 +36,7 @@ Author: Ralph Mor, X Consortium
IceConn
-IceAcceptConnection (listenObj, statusRet)
-
-IceListenObj listenObj;
-IceAcceptStatus *statusRet;
-
+IceAcceptConnection (IceListenObj listenObj, IceAcceptStatus *statusRet)
{
IceConn iceConn;
XtransConnInfo newconn;
@@ -51,7 +47,7 @@ IceAcceptStatus *statusRet;
* Accept the connection.
*/
-if ((newconn = _IceTransAccept (listenObj-trans_conn, status)) == 0)
+if ((newconn = _IceTransAccept (listenObj-trans_conn, status)) == NULL)
{
if (status == TRANS_ACCEPT_BAD_MALLOC)
*statusRet = IceAcceptBadMalloc;
diff --git a/src/authutil.c b/src/authutil.c
index 9cb3deb..3bfa324 100755
--- a/src/authutil.c
+++ b/src/authutil.c
@@ -72,7 +72,6 @@ static Status write_counted_string (FILE *file, unsigned short count, char *stri
char *
IceAuthFileName (void)
-
{
static char slashDotICEauthority[] = /.ICEauthority;
char *name;
@@ -138,15 +137,8 @@ IceAuthFileName (void)
}
-
int
-IceLockAuthFile (file_name, retries, timeout, dead)
-
-char *file_name;
-int retries;
-int timeout;
-long dead;
-
+IceLockAuthFile (char *file_name, int retries, int timeout, long dead)
{
char creat_name[1025], link_name[1025];
struct stat statb;
@@ -215,12 +207,8 @@ long dead;
}
-
void
-IceUnlockAuthFile (file_name)
-
-char *file_name;
-
+IceUnlockAuthFile (char *file_name)
{
#ifndef WIN32
char creat_name[1025];
@@ -244,12 +232,8 @@ char *file_name;
}
-
IceAuthFileEntry *
-IceReadAuthFileEntry (auth_file)
-
-FILE *auth_file;
-
+IceReadAuthFileEntry (FILE *auth_file)
{
IceAuthFileEntry local;
IceAuthFileEntry *ret;
@@ -296,12 +280,8 @@ FILE *auth_file;
}
-
void
-IceFreeAuthFileEntry (auth)
-
-IceAuthFileEntry *auth;
-
+IceFreeAuthFileEntry (IceAuthFileEntry *auth)
{
if (auth)
{
@@ -315,13 +295,8 @@ IceAuthFileEntry *auth;
}
-
Status
-IceWriteAuthFileEntry (auth_file, auth)
-
-FILE *auth_file;
-IceAuthFileEntry *auth;
-
+IceWriteAuthFileEntry (FILE *auth_file, IceAuthFileEntry *auth)
{
if (!write_string (auth_file, auth-protocol_name))
return (0);
@@ -344,14 +319,8 @@ IceAuthFileEntry *auth;
}
-
IceAuthFileEntry *
-IceGetAuthFileEntry (protocol_name, network_id, auth_name)
-
-char *protocol_name;
-char *network_id;
-char *auth_name;
-
+IceGetAuthFileEntry (char *protocol_name, char *network_id, char *auth_name)
{
FILE *auth_file;
char *filename;
@@ -387,7 +356,6 @@ char *auth_name;
}
-
/*
* local routines
Re: Intel driver + sgi 1600 sw
Hello, I reply to myself, just to tell you that i found a quick hack to my problem : The idea is to force the driver to start xorg by returning XF86OutputStatusConnected instead of XF86OutputStatusDisconnected in the function which probe for a monitor. I've stolen the idea here http://bugs.freedesktop.org/show_bug.cgi?id=14611 So it works pretty well for me, but i guess it break all the xrandr stuff Is there a better way to solve this issue ? On Sun, Oct 26, 2008 at 12:00 PM, Cyril Richard aka [ Sx ] [EMAIL PROTECTED] wrote: Hello everybody, First of all thanks for your great work ;) So my problem is i have an sgi1600sw monitor (which is great ... look here for more details http://www.siliconbunny.com/1600sw-faq/ ). It is plugged my g35 intel graphic card through to a gfx1600sw pci adapter card. This monitor use a quite special resolution which is 1600x1024. The problem is xorg can't start because the screen is not detected ... egrep \((WW|EE)\) /var/log/Xorg.0.log gives me : (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. (WW) intel: No matching Device section for instance (BusID PCI:0:2:1) found (EE) intel(0): Output TMDS-1 enabled but has no modes (EE) intel(0): No valid modes. (EE) Screen(s) found, but none have a usable configuration But when i start xorg with another monitor plugged, xorg starts, i don't see anything because this other monitor can't display 1600x1024, but if then i plug my SGI monitor, my sgi monitor is working great :) When my sgi monitor is plugged here is what xrandr gives me : VGA disconnected (normal left inverted right x axis y axis) TMDS-1 disconnected 1600x1024+0+0 (normal left inverted right x axis y axis) 473mm x 296mm 1600x1024 (0x4d) 106.9MHz h: width 1600 start 1620 end 1640 total 1670 skew0 clock 64.0KHz v: height 1024 start 1027 end 1030 total 1067 clock 60.0Hz So Is there an xorg option or anything which can force xorg to start even if it doesn't detect a monitor ? The Enable Option in the monitor section appears to have no effect ... -- Cyril Richard mail : [EMAIL PROTECTED] www : http://www.qubelab.net -- Cyril Richard mail : [EMAIL PROTECTED] www : http://www.qubelab.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xinput for whiteboards
Hello, I have been asked to create a electronic whiteboard driver for Linux. I am in the process of creating the Linux kernel driver, which is going well so far. The whiteboard not only issues coordinates but also pen size, colour and battery status. However I am going to need to send events to X so that my Qt application can pick up the x11Events() which Qt can listen for. Could anybody point me in the right direction of someone to talk to or something to read regarding how to go about this? Regards Phil Hannent signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Moving check for screensaverproto in xorg-server's configure to conditional block
Hi, running 1.5.2 xorg-server's configure with the option --disable-screensaver, I noticed that configure always checks for screensaverproto. Attached is a patch, which moves the check for screensaverproto from the main REQUIRED_MODULES block to the conditional screensaver block. Fine regards, Christoph Berg --- xorg-server-1.5.2/configure.ac.old 2008-10-20 13:16:05.643287907 +0200 +++ xorg-server-1.5.2/configure.ac 2008-10-20 13:16:54.435288163 +0200 @@ -662,7 +662,7 @@ RENDERPROTO=renderproto fi -REQUIRED_MODULES=[randrproto = 1.2] $RENDERPROTO [fixesproto = 4.0] [damageproto = 1.1] xcmiscproto xextproto [xproto = 7.0.9] xtrans [scrnsaverproto = 1.1] bigreqsproto resourceproto fontsproto [inputproto = 1.4.4] [kbproto = 1.0.3] +REQUIRED_MODULES=[randrproto = 1.2] $RENDERPROTO [fixesproto = 4.0] [damageproto = 1.1] xcmiscproto xextproto [xproto = 7.0.9] xtrans bigreqsproto resourceproto fontsproto [inputproto = 1.4.4] [kbproto = 1.0.3] REQUIRED_LIBS=xfont xau fontenc [pixman-1 = 0.9.5] dnl HAVE_DBUS is true if we actually have the D-Bus library, whereas @@ -814,6 +814,7 @@ AM_CONDITIONAL(SCREENSAVER, [test x$SCREENSAVER = xyes]) if test x$SCREENSAVER = xyes; then AC_DEFINE(SCREENSAVER, 1, [Support MIT-SCREEN-SAVER extension]) + REQUIRED_MODULES=$REQUIRED_MODULES [scrnsaverproto = 1.1] fi AM_CONDITIONAL(RES, [test x$RES = xyes]) signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
dmx-2 branch
Hey, I pushed out some DMX server work I've been doing on the dmx-2 branch. The work started out as a set of modifications to the existing DMX server but is today closer to a rewrite. The purpose of this new DMX server is slightly different from that of the original and the functionality in the dmx-2 branch is not a superset of the DMX server in master. The reason for this was simply to reduce the complexity of the new functionality I've working on. Here's a list of significant differences between dmx-2 branch and master: - Use dbus for configuration instead of config files and DMX extension. - New back-end server only input implementation that leverage MPX. - Cursor handling on back-end server side. - Proper handling of pointer and keyboard grabs. - Use of XCB for back-end server request/reply handling to avoid any unnecessary blocking and round-trips. - Composite support. - XVideo support. - MIT-SHM support. - Connection breakage support. - RANDR 1.2 support. - Map/configure request forwarding. - Window property forwarding. - Selection sharing. - XDND support. - Avahi support (not sure that this is a good idea though) All together I find the dmx-2 implementation less complex and much more maintainable. The purpose of all this work is to use Xdmx as a proxy X server on virtual machines and remote desktops. Xvnc/X11rdp can be dynamically attached to Xdmx when VNC/RDP support is desired but simply attaching a local display directly to a remote Xdmx instance can provide unmatchable performance and all the nice features (like seamless selection sharing, XDND support and local compositing) that Xdmx provides. Most changes in the dmx-2 branch are in the dmx DDX but there are some DIX changes too. Most of them are xinerama improvements or bug fixes and should be straight forward to get into master. They are not many so I'm gonna post each one of them with an explanation to the list asap. For the DDX part I'm not sure if we want to replace the existing dmx implementation or keep them separated. - david ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Rotating X Fonts?
1. Is there a way to know at run-time whether or not an X-server will actually be able to honor the rotated font request? Not officially. However, you may have a look at the font property ``RASTERIZER_NAME''. If it says ``FreeType'', ``X Consortium Type 1 Rasterizer'' or ``X Consortium Speedo Rasterizer'', it will probably work. If it's something else, all bets are off. 2. Is there any documentation/standard for the use of rotated fonts, e.g., the name of the rotated font above is mostly a mystery between the []? The XLFD spec, version 1.5, Section 4. http://www.x.org/docs/XLFD/xlfd.pdf 3. I suspect the issue might be a discrepancy between the installed fonts on the two X servers. No, it's more probably a discrepancy between the font backends being used. I suspect that Hummingbird uses a rasteriser called the ``X Consortium Bit Scaler'', which has been disabled in X.Org. Core X11 fonts are deprecated in X.Org. I strongly recommend that you switch to Xft, which doesn't have any of these issues. Juliusz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
