Intellimouse protocol 4th byte limits and AMI 150T OpticalWebScroll Mouse
Hi, I have been reading about the Intellimouse protocol and the usage of the 4th byte in the standard packet. Some documentation claims that the low order nibble is used as magnitude and the high order nibble as sign (F for negative, 0 for positive), encoded in 2's complement; This would indicate that the valid range for this input is 15 to -15. Some documents claim that the full range of 127 to -127 is valid. However, dz @ xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c:1414 is limited to 6 -6 and this certainly seems incorrect. The case in point is an AMI 150T Optical WebScroll mouse, which reports vertical scroll as 1 and -1 (FF) and horizontal scroll as 7 and -7 (F9). I have a patch to remove the checks on the limits that works for me: --- xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c.orig 2001-12-19 16:05:22.0 + +++ xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c 2003-08-31 23:55:04.0 +0100 @@ -1411,7 +1411,5 @@ dx = (pBuf[0] 0x10) ?pBuf[1]-256 : pBuf[1]; dy = (pBuf[0] 0x20) ? -(pBuf[2]-256) : -pBuf[2]; dz = (char)pBuf[3]; - if ((dz = 7) || (dz = -7)) -dz = 0; break; I also tested it with 15 -15 which worked as well. I do not know the correct solution. Hoping to be helpful Matthew Bell ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
synaptics lockups (was Re: radeon lockups ...)
Warren Turkal wrote: Michel Dänzer wrote: In that case it can hardly be an X problem. Sounds rather like the kernel (anything interesting in its output? Does the same thing happen with 2.4 kernels?) or hardware. I am testing 4.2.1 at this point to see if I come up with the same issues as with 4.3.0. Warren Turkal I came up with the same issues as with 4.3. It turns out that I was running a not-the-latest version of the synaptics event driver for XFree86. I looked in the changelog of the newest one, and it claims to have a work around for a bug in XFree86 that could cause lockups. Does this bug still exist? Here is link to the driver: http://w1.894.telia.com/~u89404340/touchpad/index.html I guess my personal suspicions that it was only locking while I was using the touchpad could have had some merit. I am sorry I did not mention that earlier. Is the synaptics driver to be included in XFree86 anytime soon since it is required with 2.6 kernels on computers with synaptics touchpads? You cannot use a regular ps2 mouse driver without lots of contortions (ie kernel options). Warren Turkal -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
howto beep in dix/main.c or some other DDX function?
Title: howto beep in dix/main.c or some other DDX function? I want to write a beep func in above.
Re: synaptics lockups (was Re: radeon lockups ...)
On Mon, 1 Sep 2003, Warren Turkal wrote: In that case it can hardly be an X problem. Sounds rather like the kernel (anything interesting in its output? Does the same thing happen with 2.4 kernels?) or hardware. I am testing 4.2.1 at this point to see if I come up with the same issues as with 4.3.0. Warren Turkal I came up with the same issues as with 4.3. It turns out that I was running a not-the-latest version of the synaptics event driver for XFree86. I looked in the changelog of the newest one, and it claims to have a work around for a bug in XFree86 that could cause lockups. Does this bug still exist? Here is link to the driver: http://w1.894.telia.com/~u89404340/touchpad/index.html I guess my personal suspicions that it was only locking while I was using the touchpad could have had some merit. I am sorry I did not mention that earlier. Is the synaptics driver to be included in XFree86 anytime soon since it is required with 2.6 kernels on computers with synaptics touchpads? You cannot use a regular ps2 mouse driver without lots of contortions (ie kernel options). It's GPL licensed unfortunately. Only MIT licensed code is accepted into XFree86, so this driver will never be included. That means once kernel 2.6 is standard, the majority of laptop users with synaptics touchpads will have to rely on their OS distribution to provide the GPL driver, or will have to compile it themselves. The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: synaptics lockups (was Re: radeon lockups ...)
On Tue, Sep 02, 2003 at 02:04:00AM -0400, Mike A. Harris wrote: It's GPL licensed unfortunately. Only MIT licensed code is accepted into XFree86, so this driver will never be included. That means once kernel 2.6 is standard, the majority of laptop users with synaptics touchpads will have to rely on their OS distribution to provide the GPL driver, or will have to compile it themselves. The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. Well, couldn't the upstream author just relicense it? -- Daniel Stone [EMAIL PROTECTED] http://www.debian.org - http://www.kde.org - http://www.freedesktop.org Configurability is always the best choice when it's pretty simple to implement -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
Re: synaptics lockups (was Re: radeon lockups ...)
On Tue, 2 Sep 2003, Daniel Stone wrote: Date: Tue, 2 Sep 2003 20:30:58 +1000 From: Daniel Stone [EMAIL PROTECTED] To: Mike A. Harris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=qjNfmADvan18RZcF Subject: Re: synaptics lockups (was Re: radeon lockups ...) On Tue, Sep 02, 2003 at 02:04:00AM -0400, Mike A. Harris wrote: It's GPL licensed unfortunately. Only MIT licensed code is accepted into XFree86, so this driver will never be included. That means once kernel 2.6 is standard, the majority of laptop users with synaptics touchpads will have to rely on their OS distribution to provide the GPL driver, or will have to compile it themselves. The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. Well, couldn't the upstream author just relicense it? That depends on wether or not the code is original code, or if it is a derivative of any other GPL sources. It's possible theoretically, but dependant on the history of the code, and also the author(s) wishes. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: synaptics lockups (was Re: radeon lockups ...)
On Tue, 2 Sep 2003, Daniel Stone wrote: The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. Well, couldn't the upstream author just relicense it? That depends on wether or not the code is original code, or if it is a derivative of any other GPL sources. It's possible theoretically, but dependant on the history of the code, and also the author(s) wishes. That was kind of implicit. To you perhaps, but not to everyone out there. Many people think you can just relicense code on a whim if you're the author, regardless of wether your work contains GPL'd bits from other things or not. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: synaptics lockups (was Re: radeon lockups ...)
On Tue, Sep 02, 2003 at 07:19:38AM -0400, Mike A. Harris wrote: On Tue, 2 Sep 2003, Daniel Stone wrote: On Tue, Sep 02, 2003 at 02:04:00AM -0400, Mike A. Harris wrote: It's GPL licensed unfortunately. Only MIT licensed code is accepted into XFree86, so this driver will never be included. That means once kernel 2.6 is standard, the majority of laptop users with synaptics touchpads will have to rely on their OS distribution to provide the GPL driver, or will have to compile it themselves. The only other option would be for someone to write a brand new driver for synaptics and license it as MIT, without looking at the GPL driver's source code. It's possible to do a clean room implementation, but I'm not sure if anyone would really want to bother when there's a working driver already. Well, couldn't the upstream author just relicense it? That depends on wether or not the code is original code, or if it is a derivative of any other GPL sources. It's possible theoretically, but dependant on the history of the code, and also the author(s) wishes. That was kind of implicit. -- Daniel Stone [EMAIL PROTECTED] http://www.debian.org - http://www.kde.org - http://www.freedesktop.org Configurability is always the best choice when it's pretty simple to implement -- Havoc Pennington, gnome-list pgp0.pgp Description: PGP signature
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: As you said a HID device is more or less unidirectional. Therefore you won't be able to detect from the device interface that something is wrong. The HID interface itself would have to provide QoS. Anyway QoS would not be part of XI but would be implemented in the HW messaging extension. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. And yes, the kernel device driver can also issues quality of service reports. In the kernel's case, there's no-one that you can specifically send reports to. With my kernel device driver, I have a diagnostic file in the procfs that something could monitor for complaints... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. Correct. My outlook is a more generic client -- driver API (remember I use the word client very loosely -- it could be the parse XF86Config file, tell drivers to load into memory, and configure yourself to XXX client. Because face it, what's unique about an input device that it needs a special status-reporting, state-setting, loading/unloading self to hotplug events API? Well, maybe we should first define the word 'client' so we are sure to talk about the same thing. When I say 'cleint' I mean X client (ie. any application connecting to the server thru the protocol). Your definition and mine are very similar. I would continue the definition to say that even intrinsic server functions, like loading a driver into memory, can be initiated by a client. Why? Because I would want to keep the actual server separate from these ancilliary functions. Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Darn! What I offered later in the mail thread you didn't see value in, either. I'll either have to send you to some white papers talking about other products doing QoS, or think of a better example for you... That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. Don't forget, the same select() loop also receives X events and you don't want the server to appear sluggish while dealing with non-core events. So yeah, spawning a thread to deal with them is not a bad idea. Right. That's what we need a registry for. I think your registry would know how to identify hardware and determine the correct drivers to load. But are you also suggesting that it knows how to ask the NVidia driver for its video resolution (e.g., it prefers a message in string format like, reso?, whereas the CT driver might use a different message?) Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... OK, you want to start with the HW interface. Ah, no. HID tries to standardize hardware attributes for different devices into common terminology. Then they define standard messages for setting attributes and querying attributes from the hardware, given a standardized language. (Actually, enums) Their specs barely acknowledge that it's running on USB :-) But it's the beginning of figuring out what attributes different types of hardware would have, and creating standardized terms for everything. (I believe) they made a few mistakes, but it's still something to learn from. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Completely agree. The X-client interface should only be concerned with the message format. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Resume
. Resume from:Rich for JoborServiceno job too small E L E C T R I C I A N Tel. (408) 482-2102 [EMAIL PROTECTED] WIRING INSTALLATION Hands on electrical installations perform fitting, mounting, laying cables on Commercial, Industrial, residential new existing buildings. Electrical Power Supply for Lights, Plugs, Receptacles, Panels, Fuse boxes, Emergency Generators wiring and testing, Transformers, Power Lines conduit layout, bending and mounting, parking lighting, lamps, switches, SOLAR PROJECTS, posts and underground installations. Shopping Centers; grocery stories, hardware stories, restaurants residential - housing areas, computer business fast food units installation buildings; Solar Panels, Sun Tracking, Flywheel Storage electric cars systems modify, Natural Energy in Remote areas install. LOW VOLTAGE forHOME OFFICE 12 / 24 Volt audio video equipment, Computer data network wiring, data backup and UPS; Monitoring Video Control backup tapes set up and mounting, electro-optical assemblies subsystems. DC Power Supply, Switch Motion sensors Alarm. Fire safety systems install. Fiber Optics systems, PLC setup, Master Control Center, cable modems cable TV install. Network, UPS Battery Backup mounting and charging systems; Power supply testing, troubleshooting, and analyzing to a components level. Electric Vehicles Design, Assembly Installations. CC TV Cameras, Security Systems Sensors for Safety, Fire sprinklers and traffic Monitoring Door Control. Telephones / Net move install. TECHNICIAN Use lab shop equipment, mechanical, electrical electronic tools, measurement testing equipment, video cameras microscopes. Support scientists electronic engineers. Mechanical Electro-Mech. Design. OFFICE, ELECTRICAL AND MECHANICAL PROJECTS Electrical Network Sketches, one line diagrams, and as is drawings update. Customizing Electronic and Electrical Components Parts, Layouts electronic and electrical schematic, connectors and mechanical detailing. Quotes, supply, bids and job estimating. Customers contact, inspection, project mgmt supervision of electricians material handling; Use CAD, Windows and applications; ELECTRICAL MAINTENANCE SERVICE Citizen; open for travel Tel. (408) 482-2102 [EMAIL PROTECTED] . ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin build error
Matthieu Herrb [EMAIL PROTECTED] wrote: Hi, when building the latest XFree86 on Mac OS 10.2.4, I get link errors. A first one is easily fixed by the attached patch, but XDarwinApp also fails to link with the following error for which I can't find the missing code... Yes, I have this issue fixed on my laptop. Unfortunately for the next week or so I can't commit the changes as I am away on vacation with only slow web mail access. Unfortunately this error crept shortly before I left. Here's the backstory: XDarwin is going to support two rootless implementations using different API's. On Panther (and hopefully 10.2.x) XDarwin can use Apple's new Xplugin library which was developed specifically for it. Earlier versions will have to use the mixture of Cocoa and Carbon that we used in XFree86 4.3.0. The missing xp_* symbols that you see are from libXplugin. Here's the way I have fixed this: applewm.c will be built into XDarwin as you did with your Imakefile patch. However, applewm.c is being improved to work with either the Xplugin or Cocoa implementations. The XDarwin build is also being modified so that it always builds both implementations (if possible) and dynamically loads the appropriate one in at runtime. This should make testing both implementations much easier. (This bug slipped through because I only tested it when building for Xplugin.) In the short term you can do one of the following to fix the problem: 1. Build the Xplugin implementation. To do this download Apple's X11 public beta and install it. (Actually you only need to install libXplugin, which has its own installer buried in the X11 installer bundle.) Then add the following line to your host.def file: #define XpLibDir /usr/lib Rebuild and everything should build correctly. You will also find that GLX is now exactly as fast as Mac OS X's native OpenGL. 2. Comment out the AppleWMSendEvent() call in Xserver/hw/darwin/quartz/quartz.c. You should be able to rebuild without applewm.c. --Torrey making all in programs/Xserver/miext/rootless... make[4]: Nothing to be done for `all'. /usr/bin/cc -o XDarwinApp -Os -Wall -Wpointer-arith -no-cpp-precomp -L../../exports/lib dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a hw/darwin/libdarwin.a hw/darwin/quartz/libXQuartz.a hw/darwin/quartz/cr/libcr.a miext/rootless/librootless.a hw/darwin/quartz/aquaWindow.o hw/darwin/quartz/aquaPicture.o miext/shadow/libshadow.a fb/libfb.a Xext/libext.a xkb/libxkb.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a randr/librandr.a render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libext.a xkb/libxkb.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a dbe/libdbe.a record/librecord.a XTrap/libxtrap.a randr/librandr.a render/librender.a -L/usr/X11R6/lib../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -framework IOKit -framework ApplicationServices -framework Cocoa ! -framework CoreAudio -framework Carbon -ObjC ld: Undefined symbols: _xp_configure_window _xp_disable_update _xp_frame_draw _xp_frame_get_rect _xp_frame_hit_test _xp_reenable_update make[3]: *** [XDarwinApp] Error 1 Here's the patch to build applewm.o: Index: Imakefile === RCS file: /cvs/xf86/xc/programs/Xserver/hw/darwin/quartz/Imakefile,v retrieving revision 1.9 diff -u -r1.9 Imakefile --- Imakefile 12 Aug 2003 23:47:10 - 1.9 +++ Imakefile 1 Sep 2003 21:15:30 - @@ -18,6 +18,7 @@ quartzPasteboard.c \ quartzStartup.c \ pseudoramiX.c \ + applewm.c \ aquaPicture.c \ aquaWindow.c \ $(APPLEWMSRC) @@ -32,6 +33,7 @@ quartzPasteboard.o \ quartzStartup.o \ pseudoramiX.o \ + applewm.o \ aquaPicture.o \ aquaWindow.o \ $(APPLEWMOBJ) Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Your definition and mine are very similar. I would continue the definition to say that even intrinsic server functions, like loading a driver into memory, can be initiated by a client. Why? Because I would want to keep the actual server separate from these ancilliary functions. This is not how an X client works. X abstracts all these details from the client. The client should not have to deal with HW specific details at all. Certain exceptions to this rule make sense, I agree, but they must be considered carefully. Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Darn! What I offered later in the mail thread you didn't see value in, either. I'll either have to send you to some white papers talking about other products doing QoS, or think of a better example for you... I did see the examples later in the message. So far X doesn't send QoS messages to the user. Most of the time these things are expected to be handled by the driver as good as it can. If it cannot handle them the condition is usually fatal anyway. Such things get recorded in the log file as this is something the 'administrator' will have to deal with. When a read returns unexpectedly this usually doesn't point to a problem the user can deal with. If somebody cuts the cable this would either result in a normal unplug event (in case of a USB device) with the result that the client will receive the message that the device has been unregistered or remain unnoticed altogether (serial device). I do understand the 'the battery in the cordless mouse is getting low' message. This would better live in the hardware messaging, ie. the successor of todays xf86misc extension. That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. Don't forget, the same select() loop also receives X events and you don't want the server to appear sluggish while dealing with non-core events. So yeah, spawning a thread to deal with them is not a bad idea. How much traffic do you expect? Right. That's what we need a registry for. I think your registry would know how to identify hardware and determine the correct drivers to load. But are you also suggesting that it knows how to ask the NVidia driver for its video resolution (e.g., it prefers a message in string format like, reso?, whereas the CT driver might use a different message?) That's why we need a registry. And I don't like string messages either. This is the current ad hoc implementiaton. Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... OK, you want to start with the HW interface. Ah, no. HID tries to standardize hardware attributes for different devices into common terminology. Then they define standard messages for setting attributes and querying attributes from the hardware, given a standardized language. (Actually, enums) Their specs barely acknowledge that it's running on USB :-) OK. But it's the beginning of figuring out what attributes different types of hardware would have, and creating standardized terms for everything. (I believe) they made a few mistakes, but it's still something to learn from. OK. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Completely agree. The X-client interface should only be concerned with the message format. OK. Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: As you said a HID device is more or less unidirectional. Therefore you won't be able to detect from the device interface that something is wrong. The HID interface itself would have to provide QoS. Anyway QoS would not be part of XI but would be implemented in the HW messaging extension. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. Are you sure? We'd have to check why the read would error out. It would do so if the device was closed because it was removed. That's a normal event when a device is hot pluggable. If XI supports removing of devices it would just notify the XClient of the removal. The coordinate issue is a device - driver compatibility problem. Do we want to report this to the client, or is it sufficient to tell the user about the problem in the log file. And yes, the kernel device driver can also issues quality of service reports. In the kernel's case, there's no-one that you can specifically send reports to. With my kernel device driver, I have a diagnostic file in the procfs that something could monitor for complaints... Do you have to obtain this information from a dedicated diagnostics file, couldn't you read it from the general kernel log? I do understand QoS notifications where one deals with frequently occuring conditions that require rapid action - like battery low information, but all cases of software of hardware failure are exceptional incidences that would be sufficient to log. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Help on creating a Window Manager
On Tue, 2 Sep 2003 13:53:07 -0700 [EMAIL PROTECTED] (Heather Stern) wrote: Those would include aewm (which I think had the same intention - a pure ICCCM rendition), ratpoison (avoiding fat libraries and I missed the original message so perhaps this was already mentioned, but I tried one called wm2 which is almost the most primitive window manager possible - you can resize close windows and bring up a menu to launch Xterm. Changing anything requires hacking the source, there are no configurable features. You can apt-get it on Debian. Mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
X for a cramped PC environment
Howdy folks. I'm part of a development project which works on a bootable business card (LNX-BBC, at www.lnx-bbc.org). At present with some config work (and a scalpel during the install phase of or builds) we use a tinyX/Kdrive based framebuffer server, and a seriously trimmed down set of fonts. (Specifically, we wanted modifiable as well as free-to-distribute, and needed to trim space a lot) We're moving our build system towards being a cross-compilation style build. I say style because even though the build hosts are linux-i386, and the normal build of the disc is for linux-i386, making it treat the environment as if cross-compiled is resulting in far better self-consistency. However, it's hell on anything that thinks it can spot being cross-compiled by deciding that some small sample binary doesn't work - because it would. Some of our dev team are also working on other platforms - not very far along yet - and those will *actually* be cross-compiled. I would expect that Kdrive should be especially amenable to this sort of teasing since it would normally be cross-compiled into say, handhelds. But if I can get something which is nearly as tiny and still contains the TTF rendering ability while supporting a config file then we can treat mice much more kindly too. I realize it's a bit vague as yet, but I'm looking into the following experiments, so if anyone has already gone into these, feel free to point me into the applicable archive thread or chime in. (And yes, I'm on the list; no need to cc me unless you're taking stuff private.) So I'm wondering if: 1. anyone has been experimenting with X that's almost so tiny as tinyX, and liked what they got? 2. kdrive is an easier option instead of a patch kit in newer code than 4.2.1? 3. anyone else has tried this weird thought towards cross compile, or if anyone with normal cross compile experience has a pointer to avoidable gotchas. 4. anyone knows a truetype/scalable cursor font? (the plan is to build an X server with *only* the TTF renderer, and tweak the limited number of X apps in our environment to use fonts we have present. For fixed there's a TTF 6x13 font that uses X's glyphs and ought to do if scalable fonts do poorly there.) At present we seem to get a clean build but the install is funny, and that's not in the part where I'm trimming font files out. A server imply oesn't end up in the final build tree. TIA everyone. . | . Heather Stern | [EMAIL PROTECTED] ---*--- Starshine Technical Services - * - [EMAIL PROTECTED] ' | ` Sysadmin Support and Training |(800) 938-4078 The bugs you have to avoid are the ones that give the user not only the inclination to get on a plane, but also the time. -- Kay Bostic ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
We can help
Introducing VP-RX Pills. VP-RX will Expand, Lengthen and Enlarge your Penís 3+ Inches! 100% Satísfaction Guaranteed! Visit our site: http://www.98207.biz/mka/m2c.php?man=st4vp * Totally confidential, no one needs to know! * No embarrassing doctor or pharmacy visits! * We have sold over 1 million bottles! * If you don't like our product don't keep it, send it back for a 100% money back refund! I want to be removed from future ads: http://www.98207.biz/bek/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
