[PATCH] xfree86: AllowEmptyInput is true by default - update the xf86Info defaults.
AEI is true if we expect to get the devices from HAL. With
d936a4235c9625bd41569cef3452dd086284e0d7, AEI also triggers the console RAW
mode.
AEI is set depending on AutoAddDevices and AutoEnableDevices, but only if a
configuration file is present. If not, the console is opened before we can set
it and RAW mode is never set.
So let's simply set it to TRUE as default, since that's what it is by default
anyway (AutoAddDevices and AutoEnableDevices are true by default).
And while we're at it, switch the rest of the defaults over to named
intializers.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
hw/xfree86/common/xf86Globals.c | 55 ---
1 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index f72f1b6..11d643d 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -98,37 +98,38 @@ InputInfoPtr xf86InputDevs = NULL;
/* Globals that video drivers may not access */
xf86InfoRec xf86Info = {
- -1, /* consoleFd */
- -1, /* vtno */
- FALSE, /* vtSysreq */
- SKWhenNeeded, /* ddxSpecialKeys */
- -1, /* lastEventTime */
- FALSE, /* vtRequestsPending */
- FALSE, /* dontVTSwitch */
- FALSE, /* dontZap */
- FALSE, /* dontZoom */
- FALSE, /* notrapSignals */
- FALSE, /* caughtSignal */
- NULL, /* currentScreen */
+.consoleFd = -1,
+.vtno = -1,
+.vtSysreq = FALSE,
+.ddxSpecialKeys = SKWhenNeeded,
+.lastEventTime = -1,
+.vtRequestsPending = FALSE,
+.dontVTSwitch = FALSE,
+.dontZap= FALSE,
+.dontZoom = FALSE,
+.notrapSignals = FALSE,
+.caughtSignal = FALSE,
+.currentScreen = NULL,
#ifdef CSRG_BASED
- -1, /* screenFd */
- -1, /* consType */
+.screenFd = -1,
+.consType = -1,
#endif
- FALSE, /* allowMouseOpenFail */
- TRUE, /* vidModeEnabled */
- FALSE, /* vidModeAllowNonLocal */
- TRUE, /* miscModInDevEnabled */
- FALSE, /* miscModInDevAllowNonLocal */
- Pix24DontCare, /* pixmap24 */
- X_DEFAULT, /* pix24From */
+.allowMouseOpenFail = FALSE,
+.vidModeEnabled = TRUE,
+.vidModeAllowNonLocal = FALSE,
+.miscModInDevEnabled= TRUE,
+.miscModInDevAllowNonLocal = FALSE,
+.pixmap24 = Pix24DontCare,
+.pix24From = X_DEFAULT,
#ifdef __i386__
- FALSE, /* pc98 */
+.pc98 = FALSE,
#endif
- TRUE, /* pmFlag */
- LogNone,/* syncLog */
- FALSE, /* kbdCustomKeycodes */
- FALSE, /* disableRandR */
- X_DEFAULT /* randRFrom */
+.pmFlag = TRUE,
+.log= LogNone,
+.kbdCustomKeycodes = FALSE,
+.disableRandR = FALSE,
+.randRFrom = X_DEFAULT,
+.allowEmptyInput= TRUE
};
const char *xf86ConfigFile = NULL;
const char *xf86InputDeviceList = NULL;
--
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] close sockets in AbortServer()
Hi,
while implementing or testing new features, I'm getting tired of having
to remove the /tmp/.X11-unix/X0 socket that's left around when X
crashes. The attached patch fixes it.
I wonder if there are reasons for not doing that, or if it's some
oversight (may be the xtrans implementation for other kind of local
transports doen't need cleanup ?)
If there are no objections I'll commit it.
--
Matthieu Herrb
diff --git a/os/log.c b/os/log.c
index ca93eb8..d443aba 100644
--- a/os/log.c
+++ b/os/log.c
@@ -416,6 +416,7 @@ void AbortServer(void) __attribute__((noreturn));
void
AbortServer(void)
{
+CloseWellKnownConnections();
OsCleanup(TRUE);
CloseDownDevices();
AbortDDX();
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Eric Anholt wrote: I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. With 2.3.1 an announce was sent to xorg-announce. Seeing as this affects xorg etc. it would probably be nice to do this (although I grant that it's not officially part of an xorg release) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 3d very slow on 945GM using intel driver
Same here w/i915. and glxgears shows only 70-75 fps... On Mon, Oct 20, 2008 at 2:02 PM, Clemens Eisserer [EMAIL PROTECTED] wrote: Same here, cannot play many games which run absolutly pefect with Windows-Drivers because of low performance. Tuxracer-0.69 is only playable at low resolutions and tuxracer-1.1-demo stutters at 5-15fps, its the same with other OpenGL apps. - Clemens 2008/10/20 Christoph Groth [EMAIL PROTECTED]: Hello, I'm running Debian testing on a Dell Latitude D430 which has the 945GM chipset. I'm using the intel driver in xorg.conf. Everything seems to work including direct rendering but still OpenGL programs are extremely slow. For example, extreme tux racer with all extra effects disabled runs at 7-8 fps at 800x600. Searching the web didn't reveal any solution. I tried a more recent xserver-xorg-video-intel package from Debian experimental (2.4.2), but this also didn't help. Now I wonder whether there is any trick to make 3d less slow on my machine? I attach the output of glxinfo, cat /var/log/Xorg.0.log, and dmesg. thanks Christoph ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] close sockets in AbortServer()
On Mon, 2008-10-20 at 12:35 +0200, Matthieu Herrb wrote: Hi, while implementing or testing new features, I'm getting tired of having to remove the /tmp/.X11-unix/X0 socket that's left around when X crashes. The attached patch fixes it. I wonder if there are reasons for not doing that, or if it's some oversight (may be the xtrans implementation for other kind of local transports doen't need cleanup ?) Abstract unix sockets in Linux don't need explicit cleanup, but they're a pretty recent innovation as far as xtrans is concerned. If there are no objections I'll commit it. Ack, please do. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Hi , Since xf86-video-intel 2.5 needs libdrm 2.4.0 , we need Mesa 7.2 ? or is enough ? just upgrade libdrm , and compile xf86-video-intel 2.5 for xserver 1.4.2 Thanks, On Sun, 2008-10-19 at 12:16 -0700, Eric Anholt wrote: On Sun, 2008-10-19 at 20:50 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. libdrm 2.4.0 is released. http://dri.freedesktop.org/libdrm/ I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Sunday, October 19, 2008 11:50 am Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. That should be defined in the libdrm headers. According to http://dri.freedesktop.org/libdrm/ there's a 2.4.0 release now, but I haven't seen the announcement yet... maybe Eric's mail didn't make it through? So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). Hm, that sounds bad... What kind of DRM errors are you seeing? If it's just these: [drm:i915_getparam] *ERROR* Unknown parameter 5 [drm:i915_getparam] *ERROR* Unknown parameter 5 that should be ok. That's just the 2D driver checking for GEM (we should probably make the messages a little less threatening, but really they're normal for non-GEM configurations). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. This is the failed to pin back buffer error? -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Sunday, October 19, 2008 12:16 pm Eric Anholt wrote: On Sun, 2008-10-19 at 20:50 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : This is mainly a smoke test for the final 2.5.0 release which I hope to do on Monday. Please give it a try and let me know if you run into build issues, etc. configure wants libdrm 2.4.0 which has yet to be released. I've tried tweaking configure.ac to get it to build on non-GEM drm (which was announced to be still supported for 2.5, iirc) but then I get massive failure in src/i830.h about dri_bo being undefined. So I gave up and installed mesa and libdrm from git, but then I get DRM errors in dmesg and rendering errors in Firefox 3 and gnome-terminal (both of which use render). And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. libdrm 2.4.0 is released. http://dri.freedesktop.org/libdrm/ I couldn't find any clearer release process for it than tag it and dump a tarball into this directory -- if any other DRM maintainer-types want to suggest an appropriate process, I'd love to hear. Yeah I guess it's not common to send out announcements about libdrm releases, but maybe we should start. Following the X.Org announcement template would be a good way to go I think, and would allow people to see what changes the release includes, etc. Anyway glad it's finally out; that means we can release 2.5.0. /me trolls the bug list to see if there are any last minute blockers. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Blend modes take 3
On Sun, 2008-10-19 at 01:54 +0200, Soeren Sandmann wrote: This sort of suggests that instead of adding all the PDF blend modes as separate operators, they could instead be given as modifiers to an existing operator. For example, you could then specify IN and MULTIPLY, and the result would be IN, MULT 0 0D * S0 I think that's an interesting result from an academic perspective, but it's not obvious to me that it will be worthwhile to pursue this. As evidence, look at the Conjoint and Disjoint operators in the Render specification. These came about when Keith found a generalization of the Porter-Duff operators that led to a family of operators that happened to include one non-Porter-Duff operator he'd already added to Render, (SATURATE). The generalization was even hinted at in the original Porter-Duff paper, where it says that the assumption of uncorrelated coverage could be improved: if we know that the coverage seldom overlaps (adjacent segments of a continuous line) or always overlaps (repeated application of a picture) So mathematically speaking, the generalization was quite justified. But in practice, it wasn't very useful. I did actually write one application that used it, (and that gave the impetus to Keith to invent the implementation of these operators). But when it came time to expose Render's operators in cairo 1.0 we dropped all the Conjoint and Disjoint variants. There was not any measurable application demand for these, and they would not map at all well onto any backends other than Render. So I'd suggest just naming the new equations as operators with the same names as PDF rather than introducing a new notion of blend mode. -Carl signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
Jesse Barnes a écrit : And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. This is the failed to pin back buffer error? I would say yes. dmesg says : [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged while Xorg.0.log says : (II) intel(0): xf86BindGARTMemory: bind key 5 at 0x03bff000 (pgoffset 15359) (EE) intel(0): Failed to pin back buffer: Cannot allocate memory Fatal server error: Couldn't bind memory for BO back buffer I've attached full logs on the intel-gfx mailing list : http://lists.freedesktop.org/archives/intel-gfx/2008-October/thread.html#348 Thanks ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Tue, 2008-10-21 at 00:11 +0200, Rémi Cardona wrote: Jesse Barnes a écrit : And if I start a GEM kernel, X doesn't even start. See my previous post on intel-gfx. This is the failed to pin back buffer error? I would say yes. dmesg says : [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty [drm:i915_gem_object_pin] *ERROR* Failure to bind: -123[drm:i915_gem_idle] *ERROR* hardware wedged while Xorg.0.log says : (II) intel(0): xf86BindGARTMemory: bind key 5 at 0x03bff000 (pgoffset 15359) (EE) intel(0): Failed to pin back buffer: Cannot allocate memory Fatal server error: Couldn't bind memory for BO back buffer The Legacy3D FALSE option may help you bring the GEM environment up in a limited-aperture-space situation. On our end, we should also cut back the EXA offscreen space in the presence of limited aperture to increase the chance of success. Also, we could use Legacy3D as a signal that it's safe to resize the framebuffer, and actually do that. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.4.98
On Mon, 2008-10-20 at 19:48 +0100, Sergio Monteiro Basto wrote: Hi , Since xf86-video-intel 2.5 needs libdrm 2.4.0 , we need Mesa 7.2 ? or is enough ? just upgrade libdrm , and compile xf86-video-intel 2.5 for xserver 1.4.2 No, it needs libdrm 2.4.0. That doesn't imply anything about mesa required. libdrm should always be safe to upgrade. If it isn't, we're doing something wrong. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 3d very slow on 945GM using intel driver
On Mon, 2008-10-20 at 17:05 -0700, Keith Packard wrote: On Mon, 2008-10-20 at 15:11 +0200, Adam Lantos wrote: Same here w/i915. and glxgears shows only 70-75 fps... 70-75fps sounds like sync to vblank ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 3d very slow on 945GM using intel driver
On Tue, 2008-10-21 at 01:09 +0100, Steven J Newbury wrote: On Mon, 2008-10-20 at 17:05 -0700, Keith Packard wrote: On Mon, 2008-10-20 at 15:11 +0200, Adam Lantos wrote: Same here w/i915. and glxgears shows only 70-75 fps... 70-75fps sounds like sync to vblank Not if it changes; vblank glxgears should be wired to the refresh rate. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 3d very slow on 945GM using intel driver
On Mon, 2008-10-20 at 17:17 -0700, Keith Packard wrote: On Tue, 2008-10-21 at 01:09 +0100, Steven J Newbury wrote: On Mon, 2008-10-20 at 17:05 -0700, Keith Packard wrote: On Mon, 2008-10-20 at 15:11 +0200, Adam Lantos wrote: Same here w/i915. and glxgears shows only 70-75 fps... 70-75fps sounds like sync to vblank Not if it changes; vblank glxgears should be wired to the refresh rate. Yes, of course, but I assumed Adam meant 70-75 as in a value around that. I could easily be wrong in that assumption, it's clear he's having other problems. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: 3d very slow on 945GM using intel driver
On Tue, 2008-10-21 at 01:28 +0100, Steven J Newbury wrote: Yes, of course, but I assumed Adam meant 70-75 as in a value around that. I could easily be wrong in that assumption, it's clear he's having other problems. Yeah, hence my assumption that he's not getting HW accel, but you're right, I shouldn't have assumed that '70-75' was a variable number :-) -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.5.0
Well, here it is (finally!). Lots of changes in this release (see below for the shortlog download URLs). We planned several things for this release: 1) usable EXA support 2) support for GEM (if supported by the currently running kernel) 3) support for kernel mode setting (again, if the underlying kernel supports it) 4) no more video tearing with textured video XvMC 5) Bug fixing 6) removal of XAA code Item (4) was the main thing we missed this time (Nanhai has been working flat out to get MPEG2 offload working so we didn't get a chance to try different approaches for vblank sync'ing). I think the real fix here will be DRI2, which should allow us to run compositing managers in DRI mode, with real vblank sync'ing for all their drawing. Also, I didn't follow through with my threat to remove XAA, even though EXA improved significantly this time around (especially with post-1.5 X servers). The blocker list was almost completely cleared out. We still have a few issues (including a Sony/GM45 related problem we still don't understand), but overall all our bug fixers deserve a big thank you. GEM support is looking great now, and is now in upstream Linux, so should be part of the 2.6.28 release. Kernel mode setting support is also included, though the kernel bits aren't queued up yet. Small patches will be needed when it finally lands upstream, mainly for mapping pixmaps through the GTT for better fallback handling. This release also includes UXA, a new acceleration architecture Keith put together specifically for UMA machines. It does its own pixmap management, but as a result really wants the same sort of GTT mapping interface that we need for kernel mode setting. I'm hoping to have that fixed up this week (again this means small patches on top of 2.5.0 to get good performance). This release requires libdrm 2.4.0 which was recently released, but should work on both GEM and non-GEM enabled kernels. It should also build work against old X servers (theoretically going back to 1.3 I think, but I haven't tested that configuration recently). So please pull this release down and give it a try. As usual, report bugs to bugs.freedesktop.org and use xorg@ and intel-gfx@ for questions and development discussion. Thanks, Jesse Adam Jackson (2): Don't touch pScrn-monitor-DDC directly. Fix Mac mini crash in DDC mode probe Alan Coopersmith (1): Man page typo fixes Bryce Harrington (1): Add TV out quirk for HP Compaq nx6110 Carl Worth (17): Move VERTEX_BUFFERS setup from prepare_composite to composite Allow for multiple vertex buffers (though only use one for now) Use up to 256 separate vertex buffers Add intel_statuspage to .gitignore Add OUT_RELOC macro and backing intel_batch_emit_reloc function Switch to using a buffer object for the vertex buffer Eliminate unnecessary flush from i965_composite Add call to intel_bufmgr_gem_enable_reuse Call DRM_I915_GEM_THROTTLE from I830BlockHandler Examine picture repeatType as well as repeat field. Add support for RepeatPad and RepeatReflect. Prefer repeatType field over using both repeat and repeatType. Fallback to software for RepeatNone with transformed RGB-only pictures. Revert Fallback to software for RepeatNone with transformed RGB-only pictures. Rename default_color to border_color Document and use 'legacy' border color mode Disable frame buffer compression by default for GM965. Daniel Stone (1): i830: Fix timer leak Dave Airlie (3): [gem] remove one more unused bit intel: fix drm check. mode: fix missing comma David Schleef (1): Bug #17277: fix upscaling limit Eamon Walsh (2): Remove unused exa_pixmap_key. Change uxa private keys to integer variables. Eric Anholt (48): Add initial GEM hacks to bring the server up. [gem] Reduce console spam from debugging. [gem] Note if pinning a buffer fails. Add a little program to dump out the first 64 dwords of the status page. Use batchbuffers instead of ring emits for general commands. Avoid needless flush emits in the blockhandler. Use the DRM for submitting batchbuffers when available. Change most usage of pixmap offsets to using a reloc macro. Use bufmgr_gem when available instead of the fake bufmgr. [gem] Don't set up the ring in GEM mode, as that'll be handled by the kernel. [gem] Chase move of create ioctl from generic to device-specific. Require libdrm 2.4.0 always since we need the bufmgr code. [gem] Catch -EINTR from blocking GEM ioctl and restart. Add little hotplug detector app. Remove VGA regs from debug output. Add DisplayPort registers. Initial HDMI work. Not currently hooked up at startup. The phase shift its are now reserved, and add HDMI clock limits. Add pixel multiplier support for HDMI Set
[ANNOUNCE] xf86-input-elographics 1.2.3
Peter Hutterer (7): Remove trailing whitespaces. Remove XFREE_V4 define and all code that expects it to be unset. Remove RCS tags. Fix build, xf86Version.h - xorgVersion.h Add Option Model to supported list of options. Add special handling for Sunit dSeries. RH #445193 elographics 1.2.3 William Brack (1): Don't convert coordinates for servers 1.4 and above. William M. Brack (1): WaitForInput before trying to xf86EloGetPacket. #14109 git tag: xf86-input-elographics-1.2.3 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.2.3.tar.bz2 MD5: cc2923460c8eff9652b01889a063058d xf86-input-elographics-1.2.3.tar.bz2 SHA1: 9485c42a79e91035447e72a3a2d1ba9a2ecbe8af xf86-input-elographics-1.2.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-elographics-1.2.3.tar.gz MD5: f1b8455700ad8ccb2d0a49b35ced1a89 xf86-input-elographics-1.2.3.tar.gz SHA1: 5d433aadb0a8494e0d46584fe352f6159265646d xf86-input-elographics-1.2.3.tar.gz signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: HAL probing for VMware vmmouse device
On Fri, Oct 17, 2008 at 05:33:33PM -0700, Philip Langdale wrote: I've attached example fdi and callout script implementations (the vmmouse-detect binary that is referred to is debian/ubuntu specific but that can be folded into a hald-probe style binary or bundled elsewhere if desired) So, one option is to write hald-probe-vmmouse and include it with the main hal package. In that case, it would not actually set input.x11_driver, but some more generic property and then the x11-input fdi would check that property to set x11_driver. Alternatively it could live outside of hal - possibly with the X11 driver package itself, but I'm concerned about how successfully it would be deployed in that situation. synaptics and wacom provide their own fdi files and they work fine. I wouldn't worry about deployment issues too much. I don't think that x11-input.fdi should check of a generic property just in case vmmouse sets it. this seems like complicating the case for the large majority of users who don't need to run vmmouse. the driver-specific fdi files are invoked after x11-input.fdi, so it's trivial to just overwrite the values with your own ones. aside from that: I don't know what the HAL's community take on the callout scripts is, but it seems like a simple enough approach. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
