[Xpert]feedback on build from CVS
I have a Dell Latitude C400 running RedHat Linux 8.0. As I am sure you can imagine, X would sorta work but was essentially unusable. Not willing to reinstall Windows, I poked around and noted that a lot of changes had been made for the Intel i830 chipset support. I checked out the latest tag that I found in the top level Imakefile and everything went fine until I got to xc/lib/XvMC/hw/i810 At this point I had to fix an include so that drm.h would be found. I'd have to look again, but I believe this was fixed in the head of the tree. So far so good, it looks sweet. I am running 1024x768 with millions of colors. One problem I ran into was when leaving X gdm would crash, and if I started up X again the pointer would be locked. I never use gdm anyway, so I found that disabling it entirely took care of the problem. Thanks for getting better support completed for my chipset, I look forward to the official release of 4.3. If there is anything in particular you would like me to look at on this system, just let me know. Regards, Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]More 6 head stuff
Lester Caine: I have 9 screens running out of the box with SUSE8. Thats impressive, but you don't have a web page to show it off! :-D The only problem nowadays is getting hold of PCI buss graphics cards, for some reason the manufacturers think that they can drop them because nobody uses them. So rather than paying UK£50-100 each I am having to pay a lot more to get reliable supplies. Perhaps I need to start looking round the antique shops g Yep, that sounds like a good idea. There is the Matrox G550 MMS card, which is a PCI card with 4 outputs. Its probably expensive, since Matrox do not even quote a price. (And the G220 MMS as well, which is available now) [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Vertical retrace and Pixmaps
On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: 1. Is there any way to detect vertical retrace in X so that the tearing down of the image can be prevented ? [...] That's exactly what I need for my application. So I came up with the following hack, (ab-)using the XF86VidMode-Extension: 1) Get the current viewport, using XF86VidModeGetViewPort. 2) Set the same viewport, using XF86VidModeSetViewPort (hoping that the driver sync with the vertical retrace when setting the viewport). 3) Do an XCopyArea or XdbeSwapBuffers to display the image. Unfortunately, this approach has 3 drawbacks: 1) It does not work with all video-drivers. It seems to work with the matrox-MGA driver (of XFree86-4.1.0). A colleague told me it worked with some nvidia-drivers as well. However, it does not work with the current ATI or Trident-drivers. 2) It uses an extension for something it was not designed for. 3) Syncing may be very expensive (as drivers usually poll and wait for the vertical retrace). You can have a look at some demos that I did: URL http://www.complang.tuwien.ac.at/skral/download/eyefriendly_xfree86/ Best Regards, Stefan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Logitech M-S48a and IMPS/2
You assume that we all build our own X !!! I have just about built the kernel and RatPoison !!! Building X is somewhat beyond my current skill set !!! :-) Owen Gunther Mayer wrote: Michael Obster wrote: It has been my experience that the wheel will not work with the M-S48A. While the M-S48 was fine the 'A' variant seems to semd wheel signals that X does not even process ! Any way my M-S48 works fine with : Section InputDevice ok. The mouse works now but as you already said without wheel. Thx for that. A question to the developer of the mouse-part. The signals, even they are strange, must be able to interpret. Otherwise everybody have also problems in other OS (I don't want to say the name now), but the mouse works there with wheel. So I think you can interpret the signals as well. Try to wake up the wheel with by sending logi_extended_s48zilog_id as found in http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + Radeon = No error + No Worky
On Thu, Oct 31, 2002 at 03:22:27PM -0600, Adam Luter wrote: Attached are my XF86Config-4 and XFree86.0.log files. I believe I have correctly setup my XF86Config-4 file, however my second monitor does not receive any signal. This time I promise not to forget to attach the files! Sorry :) -Gryn (Adam) ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc104 # Option XkbLayout us Option XkbLayout dvorak EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Device # Identifier ATI Technologies, Inc. Radeon 7500 [RV200 QW] Identifier analog port Driver ati BusID PCI:1:0:0 Screen 0 EndSection Section Device # Identifier ATI Technologies, Inc. Radeon 7500 [RV200 QW] Identifier digital port Driver ati BusID PCI:1:0:0 Screen 1 Option DigitalScreen true EndSection Section Monitor Identifier CTX:1705 HorizSync 30-95 VertRefresh 50-160 Option DPMS EndSection Section Monitor Identifier MIT:17HX HorizSync 30-82 VertRefresh 50-130 Option DPMS EndSection Section Screen Identifier Left Screen # Device ATI Technologies, Inc. Radeon 7500 [RV200 QW] Device analog port Monitor CTX:1705 DefaultDepth24 SubSection Display Depth 24 # Modes 1600x1200 1280x960 1152x864 1024x768 800x600 640x480 Modes 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection EndSection Section Screen Identifier Right Screen # Device ATI Technologies, Inc. Radeon 7500 [RV200 QW] Device digital port Monitor MIT:17HX DefaultDepth24 SubSection Display Depth 24 # Modes 1600x1200 1280x960 1152x864 1024x768 800x600 640x480 Modes 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Left Screen Screen Right Screen RightOf Left Screen InputDevice Generic Keyboard InputDevice Configured Mouse Option Xinerama On EndSection Section DRI Mode0666 EndSection ### END DEBCONF SECTION XFree86 Version 4.2.1 (Debian 4.2.1-3 20021016191246 [EMAIL PROTECTED]) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer
Re: [Xpert]Vertical retrace and Pixmaps
Thanks for the reply. But it does not work with my driver so i have still not solved my problem :( Just asking for a sugestion. Do u think switching to GLX will solve the problem? Quoting Kral Stefan [EMAIL PROTECTED]: On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote: 1. Is there any way to detect vertical retrace in X so that the tearing down of the image can be prevented ? [...] That's exactly what I need for my application. So I came up with the following hack, (ab-)using the XF86VidMode-Extension: 1) Get the current viewport, using XF86VidModeGetViewPort. 2) Set the same viewport, using XF86VidModeSetViewPort (hoping that the driver sync with the vertical retrace when setting the viewport). 3) Do an XCopyArea or XdbeSwapBuffers to display the image. Unfortunately, this approach has 3 drawbacks: 1) It does not work with all video-drivers. It seems to work with the matrox-MGA driver (of XFree86-4.1.0). A colleague told me it worked with some nvidia-drivers as well. However, it does not work with the current ATI or Trident-drivers. 2) It uses an extension for something it was not designed for. 3) Syncing may be very expensive (as drivers usually poll and wait for the vertical retrace). You can have a look at some demos that I did: URL http://www.complang.tuwien.ac.at/skral/download/eyefriendly_xfree86/ Best Regards, Stefan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + Radeon = No error + No Worky
On Fre, 2002-11-01 at 16:02, Adam Luter wrote: On Thu, Oct 31, 2002 at 03:22:27PM -0600, Adam Luter wrote: Attached are my XF86Config-4 and XFree86.0.log files. I believe I have correctly setup my XF86Config-4 file, however my second monitor does not receive any signal. This time I promise not to forget to attach the files! Sorry :) Your config looks fine to me, and the log looks similar to the one someone else posted recently, i.e. everything looks fine except the driver doesn't mention the second head at all. As I said in that other thread after looking at the source, the driver seems to ignore the second head under some circumstances I don't understand; maybe Hui Yu or Kevin E. Martin would. There's also a good chance for this to work better in current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + Radeon = No error + No Worky
Normally I wouldn't mind compiling, but I think it's understandable for X if I'm a little trepidious :) . However, I am anxious enough to do so this weekend or the next, if there aren't any other less adventourus suggestions! :) Thank you for the advice -- I'm sorry that I didn't find that earlier thread on my own. -Gryn (Adam) On Fri, Nov 01, 2002 at 04:50:37PM +0100, Michel Dänzer wrote: On Fre, 2002-11-01 at 16:02, Adam Luter wrote: On Thu, Oct 31, 2002 at 03:22:27PM -0600, Adam Luter wrote: Attached are my XF86Config-4 and XFree86.0.log files. I believe I have correctly setup my XF86Config-4 file, however my second monitor does not receive any signal. This time I promise not to forget to attach the files! Sorry :) Your config looks fine to me, and the log looks similar to the one someone else posted recently, i.e. everything looks fine except the driver doesn't mention the second head at all. As I said in that other thread after looking at the source, the driver seems to ignore the second head under some circumstances I don't understand; maybe Hui Yu or Kevin E. Martin would. There's also a good chance for this to work better in current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Savage and nVidia DRI drivers
José Fonseca wrote: Actually my main interest is the learning experience of making a DRI driver from ground up - experience which I plan to share by writing a thorough HOWTO describing the steps and explaining the working of a driver from the high-level structure to the low-level implementation details. (You already can see the very first writings on http://dri.sf.net/doc/howto/) Great! -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: State of Intel i845G support?
There is a page for this driver in XFree86.org, please take a look: http://www.xfree86.org/~dawes/845driver.html __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]But *why* no vblank?
I must have seen about 10 requests/complaints on this list about no vblank sync support since I subscribed. The reply is always the same, that the vblank signal comes on an interrupt, and a usermode program such as X cannot get anywhere near it. I assume there are a number of issues surrounding vblank support. First, how does vblank fit into a network-transparent graphics protocol like X? How would the client request a particular operation to be sync'd to vblank? Obviously this syncing should occur on the server side, since a remote client can't receive the vblank signal for the local display. Also, how could the actual sync be performed? Could we have a device like /dev/vblank that blocks on read until the vblank interrupt is sent? Or some kind of ioctl? And what are the ramifications of having video code running in both the kernel and the X server? Will kernel-level video drivers interfere with X's drivers? How does X interact with the fbdev, currently? I realize that I've just asked a bunch of questions without really answering anything. But it's very frustrating to keep reading these requests for vertical sync support, and keep seeing answers that say That's just impossible, sorry. Oh, come on. We all know it isn't impossible; it's just a hairy problem that no one seems to want to deal with. It involves a bunch of compromises that people don't want to make. But this is an extremely *basic* feature that people are demanding and it doesn't seem right to just blow them off. Scott Long ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]State of Intel i845G support?
Hey, I'm building my new PC now and I'm looking at the MSI 845G with Intel i845G graphics. Since I'm going to be running linux on this box, I'd like to know what the current support for this chipset is. I've read various reports about it, but I'd at least like to know more about it and X. Is it working from CVS? At all? Thanks for you help, hbmartin ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, Nov 01, 2002 at 09:15:44AM -0800, Scott Long wrote: I realize that I've just asked a bunch of questions without really answering anything. But it's very frustrating to keep reading these requests for vertical sync support, and keep seeing answers that say That's just impossible, sorry. Oh, come on. We all know it isn't impossible; it's just a hairy problem that no one seems to want to deal with. It involves a bunch of compromises that people don't want to make. But this is an extremely *basic* feature that people are demanding and it doesn't seem right to just blow them off. It's not impossible, but it does require a kernel driver. That makes it more than just a hairy problem for XFree86. Think about it. You'd likely need a *different* kernel module for every combination of hardware, operating system (aren't there some XFree86 supported systems that don't use loadable kernel modules?), and platform (i.e., X86 vs. Alpha vs. PowerPC, etc.). That said, it is possible to at least partially acomplish this. Right now the DRI drivers for several cards (ATI Radeon 7x000 8x00 and Matrox) support this functionality for OpenGL. It probably wouldn't be too hard to export that functionality to the rest of X. The X server could then hook into that, if available, and export it through some standard (and device independent) means. The only problem is that might create some additional dependencies between the DRI kernel modules that might be undesireable, but I don't know too much about that. Thoughts? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
But why does that even have to be an XFree86 issue? We already have fbdev drivers on Linux. It wouldn't be hard to add functionality to these drivers to get something simple like /dev/vblank that blocks until vertical sync. On Linux we already *have* video code for many common cards in the kernel. I'm not suggesting that XFree86 take on the responsibility for these drivers! What I'm saying is it doesn't seem like such a big deal to simply have *support* for a vblank mechanism. Leave the details of how it occurs up to a particular set of drivers. If people need vblank badly enough, the driver support will get written. You're right that other platforms might not support this so easily -- but so what? If people really need it, they'll write it. I guess I'm proposing some sort of X extension that allows a particular X request to be tagged as synced to vblank. For example a XCopyArea request could be preceded by another request (call it XRequestVerticalSync) that indicates to the server that the operation shouldn't be performed until a vblank period. This is a very simple change. If no driver support exists for vertical sync, the server can just politely ignore the request, and do the operation whenever it feels like it. This would at the very least provide a framework for individual driver writers to start working on a kernel interface. Scott Long On Fri, 1 Nov 2002 09:48:54 -0800 Ian Romanick [EMAIL PROTECTED] wrote: It's not impossible, but it does require a kernel driver. That makes it more than just a hairy problem for XFree86. Think about it. You'd likely need a *different* kernel module for every combination of hardware, operating system (aren't there some XFree86 supported systems that don't use loadable kernel modules?), and platform (i.e., X86 vs. Alpha vs. PowerPC, etc.). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Scott Long ([EMAIL PROTECTED]): I'm not suggesting that XFree86 take on the responsibility for these drivers! What I'm saying is it doesn't seem like such a big deal to simply have *support* for a vblank mechanism. Leave the details of how it occurs up to a particular set of drivers. If people need vblank badly enough, the driver support will get written. You're right that other platforms might not support this so easily -- but so what? If people really need it, they'll write it. I guess I'm proposing some sort of X extension that allows a particular X request to be tagged as synced to vblank. For example a XCopyArea request could be preceded by another request (call it XRequestVerticalSync) that indicates to the server that the operation shouldn't be performed until a vblank period. We already have that in XSYNC, I thought. You can definitely define a counter for vsyncs and have requests scheduled for them, at least that was my impression. Some folks in the DRI world are doing a standard device API. There are also a million different kernel module hacks that export vsync interrupts existing now, look at any of the video applications right now: we have like 4 different mga kernel modules for hardware overlay surfaces with vsync interrupts, now svgalib has their own kernel callback driver, DRI has theirs presumably for page flipping at some point, etc. I think the main reason for the lack of a standard effort is the varying requirements of the projects proposing these solutions. The mplayer folks (and some xine/etc authors) want some kernel solution that's independent of X and DRI and fbcon, since they want to support different levels of exlusive or direct access. Some other projects, such as DirectFB, only care about this in the context of fbcon itself. And then the DRI folks only care about X, and so solutions from that arena may not work outside of a running X server. Resolving this is going to be difficult: X developers don't ever seem to want to consider compatibilty with driver layers that aren't X, for one. This is a very simple change. If no driver support exists for vertical sync, the server can just politely ignore the request, and do the operation whenever it feels like it. This would at the very least provide a framework for individual driver writers to start working on a kernel interface. Getting back to this, I think we're getting there especially with the recent DRI work. It's not like _nobody_ is thinking about this issue, it is being dealt with. Join #dri-devel on freenode if you want to discuss it, that's where at least some conversation has occurred (but yeah, in the context of DRI/GL, not in the context of syncing generic X requests in the X server itself, afaik). -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Proposal for mouse speed acceleration settings
Michael Toomim [EMAIL PROTECTED] writes:
Proposal: Add a boolean option to XF86Config called
UseSmoothMouseAccel that changes the behavior of xset. If this
variable is set to true, the command `xset m [A] [B]' will mean set the
cursor movement function to `[A] * raw_mouse_speed^[B]'.
Back in May this year I sent the mail below to [EMAIL PROTECTED], but
I never got any response.
Søren
From: Soeren Sandmann [EMAIL PROTECTED]
Subject: Smoother mouse acceleration
To: [EMAIL PROTECTED]
The current mouse acceleration algorithm when the user defined
threshold is non-zero is essentially this:
if (d t)
d' = A * d
else
d' = d;
where d' is the new traveled distance, and d the distqance reported by
the mouse. The constant t is the user defined threshold, and A
(= num/den) is the user defined amount of acceleration.
There are some problems with this:
- if you set the threshold high, the mouse cursor feels
sticky. If you move the mouse at just the right speed, you
will se jerky cursor movements as the traveled distance
oscillates around the threshold.
- if you set the threshold low and the acceleration high, you
lose precision as the cursor moves too fast even on small
movements.
- if you set the acceleration low, it gets difficult to reach
to corners of the screen.
So, while this isn't terribly bad, it not really good either
Here is a patch that modifies the mouse acceleration code to use the
formula
d' = c * d^alpha + d
where d' is the new distance and d is the distance reported by the
mouse. The constants c and alpha are based on the acceleration
settings, specifically
c = 1 / (threshold / 4) ^alpha
which ensures that when the travelled distance is less then
threshold/4, the distance is not modified by more than 1. This ensures
that the threshold set by the user still corresponds to the precision
of the device.
The constant alpha is just a linear function of the user set
acceleration.
The patch also changes the default acceleration to 8/3 3, which in my
opinion is a more useful setting than 2/1 4, which is the current
default.
Søren
--- ../../../xcoriginal/programs/Xserver/hw/xfree86/common/xf86Xinput.c Tue May 21 01:50:43 2002
+++ ./hw/xfree86/common/xf86Xinput.c Tue May 21 01:49:00 2002
@@ -905,15 +905,42 @@
/*
* Accelerate
*/
- if (device-ptrfeed device-ptrfeed-ctrl.num) {
- /* modeled from xf86Events.c */
- if (device-ptrfeed-ctrl.threshold) {
- if ((abs(dx) + abs(dy)) = device-ptrfeed-ctrl.threshold) {
- valuator[0] = (dx * device-ptrfeed-ctrl.num) /
- device-ptrfeed-ctrl.den;
- valuator[1] = (dy * device-ptrfeed-ctrl.num) /
- device-ptrfeed-ctrl.den;
+ if (device-ptrfeed device-ptrfeed-ctrl.num device-ptrfeed-ctrl.den) {
+ if (device-ptrfeed-ctrl.num = device-ptrfeed-ctrl.den) {
+ valuator[0] = (dx * device-ptrfeed-ctrl.num) / device-ptrfeed-ctrl.den;
+ valuator[1] = (dy * device-ptrfeed-ctrl.num) / device-ptrfeed-ctrl.den;
+ }
+ else if (device-ptrfeed-ctrl.threshold) {
+ static int cached_num = -1;
+ static int cached_den = -1;
+ static int cached_threshold = -1;
+
+ static double c = -1;
+ static double alpha = -1;
+
+ double k;
+
+ if (cached_num != device-ptrfeed-ctrl.num ||
+ cached_den != device-ptrfeed-ctrl.den ||
+ cached_threshold != device-ptrfeed-ctrl.threshold) {
+
+ double A, t;
+
+ cached_num = device-ptrfeed-ctrl.num;
+ cached_den = device-ptrfeed-ctrl.den;
+ cached_threshold = device-ptrfeed-ctrl.threshold;
+
+ A = (double)cached_num / cached_den;
+ t = (double)cached_threshold;
+
+ alpha = A/3.0 + 2.0/3.0;
+ c = 1 / pow (t/4.0, alpha);
}
+
+ k = c * pow (dx*dx + dy*dy, 0.5 * (alpha - 1)) + 1;
+
+ valuator[0] = k * dx;
+ valuator[1] = k * dy;
}
else if (dx || dy) {
mult = pow((float)(dx*dx+dy*dy),
--- ../../../xcoriginal/programs/Xserver/include/site.h Tue May 21 01:50:43 2002
+++ ./include/site.h Tue May 21 01:17:48 2002
@@ -113,9 +113,9 @@
#define DEFAULT_INT_MAX_VALUE 100
#define DEFAULT_INT_DISPLAYED 0
-#define DEFAULT_PTR_NUMERATOR 2
-#define DEFAULT_PTR_DENOMINATOR 1
-#define DEFAULT_PTR_THRESHOLD 4
+#define DEFAULT_PTR_NUMERATOR 8
+#define DEFAULT_PTR_DENOMINATOR 3
+#define DEFAULT_PTR_THRESHOLD 3
#define DEFAULT_SCREEN_SAVER_TIME (10 * (60 * 1000))
#define DEFAULT_SCREEN_SAVER_INTERVAL (10 * (60 * 1000))
Re: [Xpert]Proposal for mouse speed acceleration settings
Soeren Sandmann wrote: Back in May this year I sent the mail below to [EMAIL PROTECTED], but I never got any response. That sucks! Would it be rude to send it again? I like the idea of changing the acceleration formula completely (as you have done) rather than introducing a new XF86Config option to change it (as I had suggested). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fre, 2002-11-01 at 19:42, Billy Biggs wrote: Some folks in the DRI world are doing a standard device API. There are also a million different kernel module hacks that export vsync interrupts existing now, look at any of the video applications right now: we have like 4 different mga kernel modules for hardware overlay surfaces with vsync interrupts, now svgalib has their own kernel callback driver, DRI has theirs presumably for page flipping at some point, etc. I think it might be a good idea to write a small abstraction library which can use the various means (DRM, svgalib, ...) that already provide this. I think the main reason for the lack of a standard effort is the varying requirements of the projects proposing these solutions. The mplayer folks (and some xine/etc authors) want some kernel solution that's independent of X and DRI and fbcon, since they want to support different levels of exlusive or direct access. Some other projects, such as DirectFB, only care about this in the context of fbcon itself. And then the DRI folks only care about X, and so solutions from that arena may not work outside of a running X server. As you can see in http://dri.sourceforge.net/IRC-logs/20020121.txt (and/or maybe some following logs), it is a long term goal of the DRI project to support other environments, but so far I'm not aware of any real effort from outside the project except maybe fbdri. You don't absolutely need an X server to use the DRM, although you probably need to act pretty much like an X server at this point. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... It is mostly someone who has time to bother to get it all done - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, 1 Nov 2002, Ian Romanick wrote: On Fri, Nov 01, 2002 at 09:15:44AM -0800, Scott Long wrote: I realize that I've just asked a bunch of questions without really answering anything. But it's very frustrating to keep reading these requests for vertical sync support, and keep seeing answers that say That's just impossible, sorry. Oh, come on. We all know it isn't impossible; it's just a hairy problem that no one seems to want to deal with. It involves a bunch of compromises that people don't want to make. But this is an extremely *basic* feature that people are demanding and it doesn't seem right to just blow them off. It's not impossible, but it does require a kernel driver. That makes it more than just a hairy problem for XFree86. Think about it. You'd likely FYI: km (http://gatos.sf.net) provides vblank support for ATI cards (mach64, rage128, radeon) for Linux 2.4.x. It should not be too hard to add support for other cards. Vladimir Dergachev need a *different* kernel module for every combination of hardware, operating system (aren't there some XFree86 supported systems that don't use loadable kernel modules?), and platform (i.e., X86 vs. Alpha vs. PowerPC, etc.). That said, it is possible to at least partially acomplish this. Right now the DRI drivers for several cards (ATI Radeon 7x000 8x00 and Matrox) support this functionality for OpenGL. It probably wouldn't be too hard to export that functionality to the rest of X. The X server could then hook into that, if available, and export it through some standard (and device independent) means. The only problem is that might create some additional dependencies between the DRI kernel modules that might be undesireable, but I don't know too much about that. Thoughts? -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]fixes@xfree86,org: /dev/null?
Hi, Some while back I sent to fixes@xfree86,org my patch to make XVideo in tdfx driver double buffered. I have had no response. Are patches wanted? Should I expect a response? Thanks, Steve ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Also, how could the actual sync be performed? Could we have a device like /dev/vblank that blocks on read until the vblank interrupt is sent? Or some kind of ioctl? Scott Long A simple suggestion: What if there was a function that simply returned the number of milliseconds since previous vblank? From this single value, both blanking interval and phase could be deduced with some simple mathematics. Kim0 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
I guess I'm proposing some sort of X extension that allows a particular X request to be tagged as synced to vblank. For example a XCopyArea request could be preceded by another request (call it XRequestVerticalSync) that indicates to the server that the operation shouldn't be performed until a vblank period. If one knew the time until vblank, one could simply wait that time, and then do a xsync. It could really be that simple. [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
I think the main reason for the lack of a standard effort is the varying requirements of the projects proposing these solutions. The mplayer folks (and some xine/etc authors) want some kernel solution that's independent of X and DRI and fbcon, since they want to support different levels of exlusive or direct access. Some other projects, such as DirectFB, only care about this in the context of fbcon itself. And then the DRI folks only care about X, and so solutions from that arena may not work outside of a running X server. Resolving this is going to be difficult: X developers don't ever seem to want to consider compatibilty with driver layers that aren't X, for one. -- Billy Biggs And exactly because things have become messy like that, one should use a method that is as simple as possible, but powerful enough. A function returning milliseconds to next vblank has no unnecessary complexity, and is still powerful enough for all purposes. [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Michel Dänzer [EMAIL PROTECTED] writes: On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? Both select and a blocking ioctl are really the wrong interface here. select() or poll() are problematical because select() waits for a condition, not an event. That is, these function calls are designed things like tell me when there is more data to read. The blocking ioctl is a pain because it means you have to devote a thread to waiting for the VBI; but it at least is well defined. Unix signals are another possibility - a real pain to program, but at least they were designed for things like this. Tell me when the next VBI occurs has very similar semantics to alarm(2). Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Owen Taylor ([EMAIL PROTECTED]): Michel Dänzer [EMAIL PROTECTED] writes: The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? Both select and a blocking ioctl are really the wrong interface here. select() or poll() are problematical because select() waits for a condition, not an event. That is, these function calls are designed things like tell me when there is more data to read. The blocking ioctl is a pain because it means you have to devote a thread to waiting for the VBI; but it at least is well defined. Unix signals are another possibility - a real pain to program, but at least they were designed for things like this. Tell me when the next VBI occurs has very similar semantics to alarm(2). I like the idea of a file descriptor that, when you read() from it, gives the timestamp of the last VBI. This has a natural mapping to hardware interrupts (unlike giving milliseconds until the next VBI as was suggested in another response, since we don't really know that), and it matches the semantics of select(). It also allows nicely for async access. Good timestamps (preferably ones matches those returned from APIs like ALSA or V4L2) are essential for most of the applications I can think of, and if anyone disagrees with me on this point let me know. :) -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
I've just chatted with Keith Packard on this. This interface (an ioctl that blocks) isn't a good one. How about a signal when vertical blanking arrives? (1st choice) That, or something we can select on? (2nd choice) - Jim Gettys Sender: [EMAIL PROTECTED] From: Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] Date: 01 Nov 2002 22:01:46 +0100 To: [EMAIL PROTECTED] Subject: Re: [Xpert]But *why* no vblank? - On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: Yes, XSYNC has the right things to allow applications to synchronize on arbitrary things (including vertical sync). If the fbdev and/or DRI folks are willing to support and export an interface, it should be possible to get the plumbing hooked up. Just make it a file descriptor we (and/or other things) can select against, and it should be something that can be pretty cross platform without much trouble: them's that don't implement it on a given platform won't get support... The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, 1 Nov 2002, Scott Long wrote: I guess I'm proposing some sort of X extension that allows a particular X request to be tagged as synced to vblank. For example a XCopyArea request could be preceded by another request (call it XRequestVerticalSync) that indicates to the server that the operation shouldn't be performed until a vblank period. This is a very simple change. If no driver support exists for vertical sync, the server can just politely ignore the request, and do the operation whenever it feels like it. This would at the very least provide a framework for individual driver writers to start working on a kernel interface. Your XRequestVerticalSync implies that this would be applied to only this client's next request. This would mean that the dispatch level code would have to make note of this, and make a call into the driver before the next request from the same client. It can't call into the driver as soon as it gets it, because the next requests it gets may be from different clients. Anyhow. If there was such a entry point into the driver, and the top-level dispatch code could delay calling it until the correct point, I could support this in NVIDIA's binary drivers. You'd have to define which request XRequestVerticalSync acted on. Ie. any request, or only certain requests. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, 1 Nov 2002 [EMAIL PROTECTED] wrote: I've just chatted with Keith Packard on this. This interface (an ioctl that blocks) isn't a good one. How about a signal when vertical blanking arrives? (1st choice) That, or something we can select on? (2nd choice) - Jim Gettys What are you trying to solve? The problem of syncing XCopyArea to the retrace? If so, how does this lead to a solution? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, 1 Nov 2002, Scott Long wrote: [...] I guess I'm proposing some sort of X extension that allows a particular X request to be tagged as synced to vblank. For example a XCopyArea request could be preceded by another request (call it XRequestVerticalSync) that indicates to the server that the operation shouldn't be performed until a vblank period. So what should an interface for syncing to vblank look like? So far, the following options have been mentioned: 1) A new X extension offering some request XRequestVerticalSync. 2) Using the already existing SYNC-extension, extending it with a server-sided counter (for vblank synchronization). Anyone in favor of one or the other option? I would prefer the latter one. Regards, Stefan ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Around 15 o'clock on Nov 1, Mark Vojkovich wrote: How about a signal when vertical blanking arrives? (1st choice) That, or something we can select on? (2nd choice) What are you trying to solve? The problem of syncing XCopyArea to the retrace? If so, how does this lead to a solution? Hook the signal up to an XSYNC counter, block the client on the counter with the XCopyArea request sitting in the request buffer. Signal fires, the client is scheduled and the CopyArea executes. For an idle X server, we should have sub-ms latency, which is sufficient for this particular task. Active X servers will have to terminate any executing request, but the signal will force an immediate reschedule so the latency will grow only by the time it takes to execute that request. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fri, 1 Nov 2002, Keith Packard wrote: Around 15 o'clock on Nov 1, Mark Vojkovich wrote: How about a signal when vertical blanking arrives? (1st choice) That, or something we can select on? (2nd choice) What are you trying to solve? The problem of syncing XCopyArea to the retrace? If so, how does this lead to a solution? Hook the signal up to an XSYNC counter, block the client on the counter with the XCopyArea request sitting in the request buffer. Signal fires, the client is scheduled and the CopyArea executes. What? Did you just say you're going to delay flushing the data to the server until some time after the retrace happens (there's a significant latency there) and you think the X-server is actually going to execute that almost immediately? If so, that will totally not work. The X-server might not even be scheduled anytime soon. Even the X-server blocking until an ioctl doesn't work very well. Not to mention that my hardware doesn't even work this way. The burden of retrace syncing needs to be left entirely to the driver. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Around 15 o'clock on Nov 1, Mark Vojkovich wrote: What? Did you just say you're going to delay flushing the data to the server until some time after the retrace happens (there's a significant latency there) and you think the X-server is actually going to execute that almost immediately? No, that would be crazy. The SYNC extension permits the client to deliver a batch of requests headed by a SYNC request which blocks that client until the specified condition is met. That client is then immediately restarted and the queued requests are executed. Getting from a signal to the driver should be a matter of moments at that point -- no context switch is required, and no additional I/O operations are necessary. It does sort of require that the X server be scheduled when the signal is delivered, but that can be done relatively easily inside the kernel. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: backporting intel 845 2d
On Fri, Nov 01, 2002 at 05:31:17PM -0800, Michael Cardenas wrote: I have backported the 2d driver of the intel 845G driver for our upcoming release of lindowsOS. In our testing, we have come across a bug which was fixed in a later series of patches. The specific bug is that the 845G driver doesn't respect the refresh rates specified in the xf86config file. From looking at the cvs commit list, I see that it was fixed in a later series of patches that include 3d support. I'm not sure what you mean by the 2d vs 3d distinction. I would like to ask if it would be possible to separate the fix for refresh rate handling from the larger 3d patch, as we don't have the time to work on the entire 3d patch (which is really two large patches) and I'm not inclined to add that much possible instability to our upcoming release. If you're referring to the changes I committed in November (which fix refresh rate handling amongst other things), then they're not easily separated out. I ended up rewriting significant parts of the 2D driver, including the mode handling. I don't have the time (or inclination) to go back to the old version of the driver. It's a can of worms, which is why I opted for the rewrite in the first place. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
As Keith says, we (in this case, not Keith, but my co-authors and myself) designed XSync with the network in mind, and to avoid both network and process scheduling latencies. The model is that you can have a whole set of requests queued (and transmitted to the server), blocked on a counter (the basic abstraction). Basically, a request says: block this connection until the counter gets to a specified value. Docs are in the tree So when the counter (in this case, a vblank counter) increments, the X server gets woken up, the X schedular sees that there was a client blocked on that counter, and it can immediately execute (one or more) request(s), already present in the input buffer of the X server. You can also get informed the counter incremented by an event, but that is slow: the event mechanism is mostly to (as in TCP) serve as a clocking mechanism, so your application can know to get the next (set) of requests to the X server for the next counter increment. In this way, we can avoid network round trip times (and multi-process scheduling latencies) and achieve very fine synchronization, either between X clients or with external events (real time, or vertical sync). All this was fully tested/debugged in the early '90's, when the UNIX desktop died; it has been the lack of driver support that has held this back. - Jim -- Jim Gettys Cambridge Research Laboratory HP Labs, Hewlett-Packard Company [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
Keith Packard [EMAIL PROTECTED] writes: Around 15 o'clock on Nov 1, Mark Vojkovich wrote: What? Did you just say you're going to delay flushing the data to the server until some time after the retrace happens (there's a significant latency there) and you think the X-server is actually going to execute that almost immediately? No, that would be crazy. The SYNC extension permits the client to deliver a batch of requests headed by a SYNC request which blocks that client until the specified condition is met. To clear things up, maybe, I think the source of the confusion is that when you say blocks that client it sounds like you're talking about processes blocking on i/o. I don't think he means the kernel stops running the client's process, but rather that the X server stops processing requests from that client, leaving them queued. -- greg ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
Hi, I thought I'd chime in on this because we've discussed the issues within the GGI/KGI group a lot. Our conclusions were as follows: A) Relying on any type of signal/process wakeup from the kernel introduces unwanted latency. B) Not using a signal results in not being able to guarantee that the process is running when the desired ray position is found. C) Most of the people wanting to use this capability want to do one of a small list of things -- flip buffers, change splitline/origin, load palette etc. D) In many cases it is the vblank, not vsync, which is the desirable condition to trigger the action, as this gives a lot more time for actions to complete before the beginning of the next frame. So we decided that although we'd support a generic wakeup-based method, the kernel side must be able to perform the most commonly used functions in C), and accept and queue a request queued to do so. So we will be adding an API to our projects for queueing such requests. Regardless of what the kernel back-end is, though, an API like XSync is needed for X. XSync is actually pretty well done. I read the XSync and the DBE extension documentation some time ago when trying to figure out if they could help implement syncronisation for the GGI X target. I seem to recall the API was there to do it but there were few if any implementations. I'd urge the X11 project to review the APIs and to also consider them from the perpective of virtual drivers (that is, X running on top of some software API) in addition to merely from a hardware level. I hope this helps firm up the resolve here to do the implementation. -- Brian ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + Radeon = No error + No Worky
The problem is caused by one of your monitor not being detected. If both of your monitors were connected during boot time (if not, try it), this is probably another instance of the monitor detection problem with some OEM cards (the card id reported by your log file indicates you have an OEM card). This problem started to surface recently with more and more OEM cards hitting market. If this is the case for you, the latest CVS code won't help too much except it'll print out a warning message. There is no workaround and we have to rewrite the monitor detection code for these cards. I'm planning to do this shortly but I don't have any OEM card on my hand at the moment. If you're willing to test, I'll send you the driver when it's ready. Hui Normally I wouldn't mind compiling, but I think it's understandable for X if I'm a little trepidious :) . However, I am anxious enough to do so this weekend or the next, if there aren't any other less adventourus suggestions! :) Thank you for the advice -- I'm sorry that I didn't find that earlier thread on my own. -Gryn (Adam) On Fri, Nov 01, 2002 at 04:50:37PM +0100, Michel Dänzer wrote: On Fre, 2002-11-01 at 16:02, Adam Luter wrote: On Thu, Oct 31, 2002 at 03:22:27PM -0600, Adam Luter wrote: Attached are my XF86Config-4 and XFree86.0.log files. I believe I have correctly setup my XF86Config-4 file, however my second monitor does not receive any signal. This time I promise not to forget to attach the files! Sorry :) Your config looks fine to me, and the log looks similar to the one someone else posted recently, i.e. everything looks fine except the driver doesn't mention the second head at all. As I said in that other thread after looking at the source, the driver seems to ignore the second head under some circumstances I don't understand; maybe Hui Yu or Kevin E. Martin would. There's also a good chance for this to work better in current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Proposal for mouse speed acceleration settings
At 02\11\01 11:52 -0800 Friday, Michael Toomim wrote: Soeren Sandmann wrote: Back in May this year I sent the mail below to [EMAIL PROTECTED], but I never got any response. That sucks! Would it be rude to send it again? I like the idea of changing the acceleration formula completely (as you have done) rather than introducing a new XF86Config option to change it (as I had suggested). The XFree86 mouse deceleration function gets dx,dy integers that are small integers in between -1 and +1 quite often. Whatever the function (formula) was, it could be replaced with these two without much change: dx' = k1 * dx * (+1 if dx 0 else -1) dx' = k2 * dx [dx is a C int, dx' is real that is added to a real sum and then later converted into a screen pixel position] Mr David Dawes was replying to some e-mail on the topic of the mouse deceleration algorithm. He told me about Opensource projects. What could be done is this: * xf86PostMotionEvent() is repeatedly called. EAch time it is called, the dx,dy and time values are saved. * an algorithm averages the last k dx (and dy) values. The function that calculates k is not too simple. Certainly k is not a constant since that can lead to a slow mouse pointer appearing to have inertia. I presume patches aiming to tweak functions ought be filed/etc away while there is not some substantially better averaging algorithm in the XFree86 source code. xf86PostMotionEvent(): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Xinput.c Craig Carey ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Changing ctrl-alt-bckspc to ctrl-alt-delete
David Dawes writes:
On Thu, Oct 17, 2002 at 02:29:19PM -0700, Mark Vojkovich wrote:
[...]
It'd be nice to make this configurable, and I'm sure that a patch
to do that would be welcome.
There may be other ways to do this via configuring the XKB
extension. But I know next to nothing about XKB.
It's currently intercepting key events before they get passed up out of
the DDX. I'm not sure how feasible it would be to intercept them after
they've been converted into X keysyms, but that might offer a more
configurable solution.
XKB definately has support for defining action keys (e.g. to switch VTs or
to kill the server) and the mappings are, of course, configurable. I thought
I had submitted a patch long ago to enable this functionality in XFree86, but
I guess I never sent it in. I'll see if I can find it in my archives.
I didn't find it, so I rewrote it. This is better way of implementing
than I did it before anyway.
The attached patch:
1) Creates a new function to process action events that can be called
both by the current code (in xf86Events.c) that intercepts special
key sequences and by XKEYBOARD's action handlers.
2) Implements handling the processing of the Terminate action
3) Updates the xkb symbol maps to have a default mapping for the
Ctrl-Alt-Backspace sequence to the Terminate action
I'll send a patch implementing other special keys in XKB as soon as I write it.
--- xc/programs/Xserver/hw/xfree86/common/xf86Events.c.link Sat Oct 19 21:22:42
2002
+++ xc/programs/Xserver/hw/xfree86/common/xf86Events.c Fri Nov 1 17:44:07 2002
@@ -253,6 +253,38 @@
}
/*
+ * Handle keyboard events that cause some kind of action
+ * (i.e., server termination, video mode changes, VT switches, etc.)
+ */
+void
+xf86ProcessActionEvent(ActionEvent action)
+{
+#ifdef DEBUG
+ErrorF(ProcessActionEvent(%d)\n, (int) action);
+#endif
+switch (action) {
+case ACTION_TERMINATE:
+ if (!xf86Info.dontZap) {
+#ifdef XFreeXDGA
+ DGAShutdown();
+#endif
+ GiveUp(0);
+ }
+ break;
+case ACTION_NEXT_MODE:
+case ACTION_PREV_MODE:
+ break;
+case ACTION_DISABLEGRAB:
+case ACTION_CLOSECLIENT:
+ break;
+case ACTION_SWITCHSCREEN:
+case ACTION_SWITCHSCREEN_NEXT:
+case ACTION_SWITCHSCREEN_PREV:
+ break;
+}
+}
+
+/*
* xf86PostKbdEvent --
* Translate the raw hardware KbdEvent into an XEvent, and tell DIX
* about it. Scancode preprocessing and so on is done ...
@@ -513,12 +545,13 @@
switch (specialkey) {
case KEY_BackSpace:
- if (!xf86Info.dontZap) {
-#ifdef XFreeXDGA
-DGAShutdown();
+#ifdef XKB
+ if (noXkbExtension) {
+#endif
+ xf86ProcessActionEvent(ACTION_TERMINATE);
+#ifdef XKB
+ }
#endif
-GiveUp(0);
-}
break;
/*
@@ -953,12 +986,7 @@
switch (key) {
case KEY_BackSpace:
- if (!xf86Info.dontZap) {
-#ifdef XFreeXDGA
-DGAShutdown();
-#endif
-GiveUp(0);
-}
+ xf86ProcessActionEvent(ACTION_TERMINATE);
break;
/*
--- xc/programs/Xserver/hw/xfree86/common/xf86.h.link Sat Oct 19 21:22:39 2002
+++ xc/programs/Xserver/hw/xfree86/common/xf86.hWed Oct 30 00:10:08 2002
@@ -197,6 +197,7 @@
void xf86InterceptSignals(int *signo);
Bool xf86EnableVTSwitch(Bool new);
Bool xf86CommonSpecialKey(int key, Bool down, int modifiers);
+void xf86ProcessActionEvent(ActionEvent action);
/* xf86Helper.c */
--- xc/programs/Xserver/hw/xfree86/common/xf86str.h.linkTue Oct 29 15:41:07
2002
+++ xc/programs/Xserver/hw/xfree86/common/xf86str.h Fri Nov 1 17:46:32 2002
@@ -1009,4 +1009,16 @@
#define MF_CLEAR_DTR 1
#define MF_CLEAR_RTS 2
+/* Action Events */
+typedef enum {
+ACTION_TERMINATE = 0,/* Terminate Server */
+ACTION_NEXT_MODE = 10, /* Switch to next video mode */
+ACTION_PREV_MODE,
+ACTION_DISABLEGRAB = 20, /* Cancel server/pointer/kbd grabs */
+ACTION_CLOSECLIENT,/* Kill client holding grab */
+ACTION_SWITCHSCREEN= 100, /* VT switch */
+ACTION_SWITCHSCREEN_NEXT,
+ACTION_SWITCHSCREEN_PREV
+} ActionEvent;
+
#endif /* _XF86STR_H */
--- xc/programs/Xserver/xkb/Imakefile.link Sat Oct 19 21:26:40 2002
+++ xc/programs/Xserver/xkb/Imakefile Thu Oct 31 22:42:57 2002
@@ -25,6 +25,11 @@
XKB_DDXDEFS = XkbServerDefines
+#ifdef XFree86Version
+XF86INCLUDES = -I$(XF86COMSRC) -I$(XF86OSSRC)
+ XF86_OBJS = xf86KillSrv.o xf86VT.o
+#endif
+
DDX_SRCS = ddxBeep.c ddxCtrls.c ddxFakeBtn.c ddxFakeMtn.c ddxInit.c \
ddxKeyClick.c ddxKillSrv.c ddxLEDs.c ddxVT.c ddxLoad.c \
ddxList.c ddxConfig.c ddxDevBtn.c xkbconfig.c
@@ -42,7 +47,7 @@
XKBMisc.o XKBMAlloc.o XKBAlloc.o XKBGAlloc.o \
$(XKBXI_OBJS)
[Xpert]Re: Proposal for mouse speed acceleration settings
Craig Carey wrote: The XFree86 mouse deceleration function gets dx,dy integers that are small integers in between -1 and +1 quite often. Whatever the function (formula) was, it could be replaced with these two without much change: dx' = k1 * dx * (+1 if dx 0 else -1) dx' = k2 * dx [dx is a C int, dx' is real that is added to a real sum and then later converted into a screen pixel position] I think we're miscommunicating here. My issue has nothing to do with problems with small integers. I just want to be able to control the mouse speed (not acceleration) with xset. Since these two issues are orthogonal, let's try to keep them in separate threads. Michael ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
