Re: [ANNOUNCE] xf86-input-fpit 1.4.0
the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. Except that you need to write a lot of input drivers - for Linux, for OpenBSD, for NetBSD, for Dragonfly etc.. In the Linux case yes you could write an fpit to Linux input layer ldisc but that only fixes the world for a single OS. Re; polling - a lot of these fpit devices have weird IRQs for the serial, you may find they are not in fact polled but need a suitable IRQ forcing. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Tue, Jun 28, 2011 at 11:02:19AM +0100, Alan Cox wrote: the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. Except that you need to write a lot of input drivers - for Linux, for OpenBSD, for NetBSD, for Dragonfly etc.. In the Linux case yes you could write an fpit to Linux input layer ldisc but that only fixes the world for a single OS. I think Piotr's email was the first time in years that I even heard of someone using this driver. I suspect the number of BSD users of this driver is rather limited but if there's loads of them I'm sure they could step forward and help with testing. Cheers, Peter Re; polling - a lot of these fpit devices have weird IRQs for the serial, you may find they are not in fact polled but need a suitable IRQ forcing. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
Thanx for maintaining the driver. AFAIK kernel input driver does not exist, and this is one of last resort to make one enjoy wonders of X. ad. testing - i still use much older version , which works fine, except pointer goes crazy under heavy load sometimes. it seems that it's serial port is polled, and machines have issues with acpi timer sources, which in combination makes bit of disaster. either way it's useable on fujitsu stylistic 2300 i happen to own. btw. recently i've thought of standarising such old devices by hardware hacking , i.e. to insert 'standariser' device inbetween computer and problem device like some once-released-never-maintained tablet, mouse, etc. such device would be simple transcoding microcontroller. ofc. for devices like tablets or laptops this is still not really applicable, as it's difficult to hack something like this inside... one of problems with such thing though is that there are not really 'standard' devices , i.e. each of them is related to some vendor , and any of them is not de facto 'standard'. greetings and thanx for good work -- On Mon, 27 Jun 2011, Peter Hutterer wrote: This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. 1.4.0 has actually seen testing in the form of loading the module, enjoying a view of a non-crashing X server (-retro too, I'm soo 80s today...) and thus deducting that the driver is bug-free. Which is more testing than previous releases have seen. Nonetheless, you may not want to control your nuclear power plants with this driver. Alan Coopersmith (1): Fill in COPYING file, add SubmittingPatches URL to README Peter Hutterer (19): Cope with XINPUT ABI 7. Fix module unloading. Remove unused bits from configure.ac Bump to 1.3.99 Purge CVS tags Remove refcount field, dropped from the server unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr. Drop close_proc, conversion_proc, reverse_conversion_proc Drop libc wrappers for free, malloc Require server 1.9, drop earlier ABI support Use GetMotionHistorySize() instead of driver-internal history Support input ABI 12 Bump minimum required server version to 1.10 Include xorg-server.h, not xorgVersion.h Reshuffle configure.ac to be more in-line with other modules Remove usage of sdkdir - not used by this driver Add 50-fpit.conf default configuration file. fpit 1.4.0 philip (1): fpit: minX/ maxX get wrongly initialized git tag: xf86-input-fpit-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.bz2 MD5: 042c95fec145d8b57ca62714131ff3f1 xf86-input-fpit-1.4.0.tar.bz2 SHA1: 9305d30ae22d37c6b5bb975adc8ecda9b1d6c5e6 xf86-input-fpit-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.gz MD5: 1f262074106c855b090295faadaedb80 xf86-input-fpit-1.4.0.tar.gz SHA1: 58c3b2f8306e5f2fa69a7636e2d74a88ca24e703 xf86-input-fpit-1.4.0.tar.gz ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Mon, Jun 27, 2011 at 10:48:55PM +0200, Piotr Gluszenia Slawinski wrote: Thanx for maintaining the driver. AFAIK kernel input driver does not exist, and this is one of last resort to make one enjoy wonders of X. ad. testing - i still use much older version , which works fine, except pointer goes crazy under heavy load sometimes. it seems that it's serial port is polled, and machines have issues with acpi timer sources, which in combination makes bit of disaster. either way it's useable on fujitsu stylistic 2300 i happen to own. btw. recently i've thought of standarising such old devices by hardware hacking , i.e. to insert 'standariser' device inbetween computer and problem device like some once-released-never-maintained tablet, mouse, etc. such device would be simple transcoding microcontroller. ofc. for devices like tablets or laptops this is still not really applicable, as it's difficult to hack something like this inside... one of problems with such thing though is that there are not really 'standard' devices , i.e. each of them is related to some vendor , and any of them is not de facto 'standard'. the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. Cheers, Peter On Mon, 27 Jun 2011, Peter Hutterer wrote: This driver is one of the legacy input drivers that you almost certainly don't want to use. Use the kernel driver instead (if one exists) or write one (if none exists). This release brings the usual input ABI updates, cleanups, etc. and one real bugfix. 1.4.0 has actually seen testing in the form of loading the module, enjoying a view of a non-crashing X server (-retro too, I'm soo 80s today...) and thus deducting that the driver is bug-free. Which is more testing than previous releases have seen. Nonetheless, you may not want to control your nuclear power plants with this driver. Alan Coopersmith (1): Fill in COPYING file, add SubmittingPatches URL to README Peter Hutterer (19): Cope with XINPUT ABI 7. Fix module unloading. Remove unused bits from configure.ac Bump to 1.3.99 Purge CVS tags Remove refcount field, dropped from the server unifdef XFree86LOADER Replace LocalDevicePtr with InputInfoPtr. Drop close_proc, conversion_proc, reverse_conversion_proc Drop libc wrappers for free, malloc Require server 1.9, drop earlier ABI support Use GetMotionHistorySize() instead of driver-internal history Support input ABI 12 Bump minimum required server version to 1.10 Include xorg-server.h, not xorgVersion.h Reshuffle configure.ac to be more in-line with other modules Remove usage of sdkdir - not used by this driver Add 50-fpit.conf default configuration file. fpit 1.4.0 philip (1): fpit: minX/ maxX get wrongly initialized git tag: xf86-input-fpit-1.4.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.bz2 MD5: 042c95fec145d8b57ca62714131ff3f1 xf86-input-fpit-1.4.0.tar.bz2 SHA1: 9305d30ae22d37c6b5bb975adc8ecda9b1d6c5e6 xf86-input-fpit-1.4.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-fpit-1.4.0.tar.gz MD5: 1f262074106c855b090295faadaedb80 xf86-input-fpit-1.4.0.tar.gz SHA1: 58c3b2f8306e5f2fa69a7636e2d74a88ca24e703 xf86-input-fpit-1.4.0.tar.gz ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. as long as it'll be maintained, well written, and pulled into mainline at all ;) now i also realized that as fpit driver uses just serial port, it could be perhaps just translated in software , and simple userspace translator similiar to how ppl used joysticks in thinkpads (i recall it was sth like gpm relay) could be used . this way relatively simple code would be created requiring no periodic mainteance, interfacing with more 'standard' X input driver. then one of obstacles here is that fpit has no gpm driver ;) but it's just general idea for possibly making such devices least mainteance-labour consuming in future and not requirin destabilising whole system by introducing third party kernel drivers written by lazy and unqualified ppl ;) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? Sending from a mobile, pardon my terseness. ~ C. On Jun 27, 2011 4:01 PM, Piotr Gluszenia Slawinski curi...@bwv190.internetdsl.tpnet.pl wrote: the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. as long as it'll be maintained, well written, and pulled into mainline at all ;) now i also realized that as fpit driver uses just serial port, it could be perhaps just translated in software , and simple userspace translator similiar to how ppl used joysticks in thinkpads (i recall it was sth like gpm relay) could be used . this way relatively simple code would be created requiring no periodic mainteance, interfacing with more 'standard' X input driver. then one of obstacles here is that fpit has no gpm driver ;) but it's just general idea for possibly making such devices least mainteance-labour consuming in future and not requirin destabilising whole system by introducing third party kernel drivers written by lazy and unqualified ppl ;) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? personally i doubt it, thus i doubt it makes any point to try to put it to vanilla. also there are other devices like tablets (like the wacom stuff), joysticks, touchpads etc. which are cursed with similiar problem - they appear as 'mere' serial device, they 'just' stream the data, yet each of them speaks bit different language. and then - they all seem to do quite same thing... xyz/buttons... ...except perhaps some 'universal' driver could be created, which would have option to transcode inbetween various input devices like those internally... so 'desperate users' could just tinker with translation rules , rather than having to modify driver itself (even though it might seem so simple...) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? hmm, as i've googled a bit for pentest.c i've realized phasing driver to linux kernel drops support for such devices for i.e NetBSD users... and it seems some users of such are in fact preferring those over linux... esp. linux gets bigger and bigger nowadays... not to mention i recall i had loads of trouble making never kernel versions work on stylistic - over 2.6.31 problems with kacpid consuming 99% cpu and hibernation started to appear, and i somehow gave up trying to investigate why after certain point... so again, some kind of user-space solution is imho better, esp. it's 'hardware' is in fact mere serial port, already supported by most OS's. btw. thanx again for updating current fpit driver :) -- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Tue, Jun 28, 2011 at 01:03:32AM +0200, Piotr Gluszenia Slawinski wrote: the standard is pretty much defined by what the driver can take. If it can't parse the protocol then the device is rather useless anyway. but really, writing a serial kernel driver is rather trivial and has a higher chance of actually working long-term than dragging the old input drivers along. as long as it'll be maintained, well written, and pulled into mainline at all ;) now i also realized that as fpit driver uses just serial port, it could be perhaps just translated in software , and simple userspace translator similiar to how ppl used joysticks in thinkpads (i recall it was sth like gpm relay) could be used . this way relatively simple code would be created requiring no periodic mainteance, interfacing with more 'standard' X input driver. once it's in the kernel, the kernel driver will fulfill exactly those requirements... imo software that doesn't require maintainance is a pipe-dream though. Cheers, Peter then one of obstacles here is that fpit has no gpm driver ;) but it's just general idea for possibly making such devices least mainteance-labour consuming in future and not requirin destabilising whole system by introducing third party kernel drivers written by lazy and unqualified ppl ;) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-input-fpit 1.4.0
On Tue, Jun 28, 2011 at 01:47:43AM +0200, Piotr Gluszenia Slawinski wrote: I believe the point is to have such a driver in the vanilla kernel, not to adopt a third-party driver. Is this hardware available anywhere besides thrift stores? personally i doubt it, thus i doubt it makes any point to try to put it to vanilla. also there are other devices like tablets (like the wacom stuff), joysticks, touchpads etc. which are cursed with similiar problem - they appear as 'mere' serial device, they 'just' stream the data, yet each of them speaks bit different language. and then - they all seem to do quite same thing... xyz/buttons... ...except perhaps some 'universal' driver could be created, which would have option to transcode inbetween various input devices like those internally... so 'desperate users' could just tinker with translation rules , rather than having to modify driver itself (even though it might seem so simple...) yeah, that is exactly what the evdev kernel interface is for :) Cheers, Peter ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
