Re: sunffb
On Tue, 31 May 2005, Martin Husemann wrote:
On Tue, May 31, 2005 at 08:23:39AM -0600, Marc Aurele La France wrote:
What does NetBSD do with the trap?
Re-enable the FPU, restore old FPU state, and retry. No signal to userland
is generated.
This is the standard lazy fpu saving game - it just did not occur to us
that userland code would try the trick played here. We are now investigating
and might special case this too. The current trap handling for this case
in NetBSD definitively is suboptimal.
Another option would be to export something like xf86{En,Dis}ableFPU() from
os-support/ and have OS-specific implementations there.
I'm not sure this is worth it.
So you're suggesting this should/will be fixed in NetBSD's kernel?
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: Touch Input Driver port 3.3.6 -> 4.x
On Wednesday 25 May 2005 08:15, Sergey Babkin wrote: > The drivers have the defaults compiled into them > which can be changed from XF86Config. The problem > is that the ELO driver has (had?) it's defaults > set to 0-16K as well, so without an explicit > setting in the config file it does not work > in any useful manner. Sorry for chiming in rather late on this one. Been away for a bit... I doubt that setting the defaults for the ELO drivers would make much difference -- the driver would still be effectively useless until calibrated. My experience with their integrated monitor/touchscreen combos has been that you can make *no* safe assumptions about the orientation of the touchpanel WRT the monitor. I think they must flip a coin each day on the assembly line or something. :) Cheers! |-| | Frederick F. Gleason, Jr. | Director of Broadcast Software Development | | | Salem Radio Labs| |-| | The nice thing about standards is that there are so many of them to| | choose from. | | -- Andrew S. Tanenbaum | |-| ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
(linux-only) keyboard driver Medved
hello fellow _xfree86_ hackers! This is a second email in a series aimed at getting code into the X server needed to use a more sophisticated way of typing --- exploiting the time information: key semantics changes according to the duration of the key press. I am providing the code to be distributed under the xfree86 version 1.1 licence. Linux provides an alternative way to read keyboard input: /dev/input/eventXXX device, provided by the "evdev" driver/module. This source provides 2 new features: 1/ every event has a timestamp, which is more precise that calling (inside X server) GetTimeInMillis Playing with the time of key events is the core point of my "rewriting plugin", so i had to make several changes to all parts of X server which handle key events. 2/ distinct hardware devices (keyboard) are reported in distinct devices/files /dev/input/event0 /dev/input/event1 ... The driver, called Medved, wraps/represents the set of evdev devices (keyboards) as 1 X keyboard. I.e. X clients see 1 _core_ keyboard --- no need to play with XInput: The driver is quite unusual, b/c it handles more file descriptors, and therefore it cannot use a higher level xf86AddInputDriver and xf86Wakeup but i have to use lower level RegisterBlockAndWakeupHandlers. and look directly at the select mask to see which of managed files/devices has input ready. While coding this driver, i realized the cause of several bugs in other drivers. I had previously communicated in http://www.mail-archive.com/devel%40xfree86.org/msg06818.html the conflict between "current state" of the 2 halves of key handling code, "separated" by xf86EventQueue. In that message, i talked about "down" bit-array, now i add, that keyc->state is impossible to use in the lower half. This (incorrect use of upper half's state in the lower half, which runs ahead in time) explain 2 bugs: 1/ XF86Config options: Option "AllowDeactivateGrabs" "yes" # C-M kp-/ steal the grab Option "AllowClosedownGrabs" "yes" # C-M kp-* kill the grabbing client simply didn't work (in situations i needed them) situation: an application stopped accepting key events (i.e. holds a synchro grab & doesn't call XAllowEvent) -> therefore keys accumulate in syncEvents (dix/events.c) w/o effecting the XKB state XKB state is not "meta & control modifiers" now, you want to steal the grab, so you press 3 keys Contol Meta kp-/ -> the first 2 events enter the queue, and the keyboard driver when processing the 3rd (kp-/) will look at the XKB state which is not "meta & control modifiers", hence it will not trigger any special function. Same applies to C-M-Fn to switch VTs (during such frozen situation). 2/ C-M-Fn occasionally leaked the Fn key into applications. When the Fn was processed before the the upper part picked C M from xf86EventQueue and changed the XKB state. This is possible when X server reads all 3 key events at once. Solution is not very flexible, though. I just look if the fixed keys (say Alt_L, Ctrl_L) are down. (Since i play a lot with the time,) medved does not use HW autorepeat. This will be explained in the next email. More hw keyboards are used in the OR mode: a key is down, if and only if it is down on any of the hw keyboards. Hotplug is handled by polling, sorry. I had to pull some functionality from the linux specific part of the "kbd" driver (lnx_kbd.c) into a shared part. I enclose these preparative changes as a patch. The driver itself is at http://maruska.dyndns.org/comp/packages/medved.tar.gz If you build xfree86 server with this patch & driver, you should notice that: - auto-repeat does not work - X mixes its monotonic time (GetTimeInMillis) with the timestamp coming from evdev devices (gettimeofday) ... with various consequences (keyboard grabbing stops working, iirc) I don't bother providing fix for this, because in the next messages i will provide - patch for linux kernel & GetTimeInMillis: preversion http://maruska.dyndns.org/wiki/kernel.html - and an alternative method of generating auto-repeat events: at last a reasonable auto-repeat, which i found lacking 2 years ago, when i started fixing (hacking around) the key-event processing in X server. --- /linux/13/x/xfree86/xc/programs/Xserver/hw/xfree86/common/xf86Events.c 2005-05-31 04:46:39.0 +0200 +++ hw/xfree86/common/xf86Events.c 2005-06-02 19:14:34.0 +0200 @@ -228,6 +228,11 @@ } +/* mmc: called from Dispatch !!! (to serve the events collected in signal handlers?) + * but more importantly from WakeupHandler (after drivers have a go on reading from their FDs)! + * But, that means that they will not be in chronological order! if i have 2 FDs for a keyboard. + * Unless either the driver handles both of them & takes care, or ... we sort them later. (todo) + */ /* * ProcessInputEvents -- @@ -1643,
several fixes for XKB
hello fellow _xfree86_ hackers!
In order to provide to my friends, and maybe one day customers, a way to type
differently, as described at http://maruska.dyndns.org/wiki/forkExtension.html
... i would like to donate a necessary infrastructure to xfree86 project,
to be distributed under the xfree86 version 1.1 licence.
I also provide patches exclusively under this license.
I'm working on the documentation (and final patches), which i will send here as
several emails, you can see a pre-version at:
http://maruska.dyndns.org/wiki/x-plugin
In this email, I provide some patches(against CVS)/fixes for XKB:
* memory allocation
in file lib/X11/XKBMAlloc.c
** off-by-one errors. bzero-ing wrong regions.
This is only triggered by a keyboard driver, which (at start) registers <256
keycodes.
It is also impossible to change the interval of *core* valid keycodes.
I have hacked a (probably unacceptable) workaround, by updating ConnectionInfo
(from DIX). A part of my work is a new keyboard driver
( http://maruska.dyndns.org/wiki/medved ), and if this workaround is not
accepted (nor easily corrected), i'll just force registering of all 256
keycodes.
** growing tables w/o never shrinking.
table of XKB actions and keysyms. (i provide comments in the patch)
* client requests for info
lib/X11/XKBGetMap.c
various vmodmap vs. modmap "incomplete cut-n-paste" bugs
* client request to change XKB configuration failing (ProcXkbSetMap)
programs/Xserver/xkb/xkb.c
if the client request does not specify (XKB) types, the request fails.
* notify event processing
in lib/X11/XKBUse.c
If number of XKB types changes (by calling apropriate functions),
the XKB-unaware applications (eg. xterm) don't notice it!
In other words (client side) synthesized core X events were not sufficiently
informative.
Next patches (some against the same files) will not contain these
modifications (i hope).
--- /linux/13/x/xfree86/xc/lib/X11/XKBGetMap.c 2003-11-17 23:20:09.0 +0100
+++ lib/X11/XKBGetMap.c 2005-04-12 22:13:22.0 +0200
@@ -150,6 +150,7 @@
register int i;
XkbClientMapPtr map;
+ if ( rep->totalSyms>0 ) {/* mmc: */
map= xkb->map;
if (map->key_sym_map==NULL) {
register int offset;
@@ -236,6 +237,7 @@
oldMap->width = newMap->width;
}
}
+ }
return Success;
}
@@ -263,8 +265,16 @@
ret = BadLength;
goto done;
}
+#if 0
+/* mmc: this probably should check that the number of actions & keysyms is the same for each keycode.
+ * But for now it doesn't, so i disable it. */
symMap = &info->map->key_sym_map[rep->firstKeyAct];
- for (i=0;i<(int)rep->nKeyActs;i++,symMap++) {
+#endif
+ for (i=0;i<(int)rep->nKeyActs;i++
+#if 0
+,symMap++
+#endif
+ ) {
if (numDesc[i]==0) {
info->server->key_acts[i+rep->firstKeyAct]= 0;
}
@@ -478,7 +488,7 @@
}
extraData= (int)(rep->length*4);
extraData-= (SIZEOF(xkbGetMapReply)-SIZEOF(xGenericReply));
-if (rep->length) {
+if (extraData) {
XkbReadBufferRec buf;
int left;
if (_XkbInitReadBuffer(dpy,&buf,extraData)) {
@@ -683,6 +693,8 @@
req = _XkbGetGetMapReq(dpy, xkb);
req->virtualMods = which;
+/* mmc: we want this information, so the mask must be set! */
+req->partial = XkbVirtualModsMask;
status= _XkbHandleGetMapReply(dpy, xkb);
UnlockDisplay(dpy);
@@ -740,6 +752,7 @@
req = _XkbGetGetMapReq(dpy, xkb);
req->firstModMapKey = first;
req->nModMapKeys = num;
+req->partial = XkbModifierMapMask; /* mmc: once again (see above) */
if ((xkb!=NULL) && (xkb->map!=NULL) && (xkb->map->modmap!=NULL)) {
if ((num>0)&&(first>=xkb->min_key_code)&&(first+num<=xkb->max_key_code))
bzero(&xkb->map->modmap[first],num);
@@ -767,9 +780,10 @@
LockDisplay(dpy);
req = _XkbGetGetMapReq(dpy, xkb);
+req->partial = XkbVirtualModMapMask;
req->firstVModMapKey = first;
req->nVModMapKeys = num;
-if ((xkb!=NULL) && (xkb->map!=NULL) && (xkb->map->modmap!=NULL)) {
+if ((xkb!=NULL) && (xkb->server!=NULL) && (xkb->server->vmodmap!=NULL)) {
if ((num>0)&&(first>=xkb->min_key_code)&&(first+num<=xkb->max_key_code))
bzero(&xkb->server->vmodmap[first],num*sizeof(unsigned short));
}
--- /linux/13/x/xfree86/xc/lib/X11/XKBMAlloc.c 2003-11-17 23:20:09.0 +0100
+++ lib/X11/XKBMAlloc.c 2005-06-02 16:01:39.0 +0200
@@ -363,7 +363,7 @@
Status
XkbResizeKeyType( XkbDescPtr xkb,
int type_ndx,
- int map_count,
+ int map_count, /* number of mappings: modifier-set -> level */
Bool want_preserve,
int new_num_lvls)
{
@@ -596,6 +596,7 @@
int nCopy;
nCopy= nKeySyms= XkbKeyNumSyms(xkb,i);
+/* i could invert these following 2 IFs: */
if ((nKeySyms==0)&&(i!=key))
continue;
if (i==key)
@@ -610,6 +611,22 @@
_XkbFree(xkb->map->syms);
xkb->map->syms = newSyms;
xkb->map->num_syms = nSyms;
+
+
+/
