linuxconsole-dev Mailing List for Linux Console Project (Page 115)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> It didn't compile. Attached is the patch I used to get it to compile.
> Didn't test it yet (box is at home, I'm at work :-)

Applied.

> OK thanks a lot I'll try that and report.
> 
> BTW, would it be possible to become a linuxconsole develloper
> so that the ruby-fied pm3fb would live on sourceforge ?

Yes. Just send me your sourceforge account name. 

Hello,

Another question: how are organized the data in fb_image->data,
in particular for weird size and small depth ?

i.e. for a 6x11 font, each char is width == 6, height == 11,
depth == 1. how are the 66 bytes put in data ? I assume
byte-padded (i.e. 11 bytes for a char, with a two-bits-wide
left column for padding), is it a valid assumption for _all_
fb_image ?

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Hello,

I have a few questions on the subject of porting a driver
to ruby:

1) is it legit to extend fb_info ? i.e. using another
struc xxfb_info w/ a fb_info field first, and using
that in place of regular fb_info (like it's done
in 2.4 and in the ruby atyfb)

2) where is filled fb_fix_screeninfo ? skeletonfb
doesn't mention it. I believe it's in _set_par,
but I'd like to be sure.

3) are the optional functions (_ioctl, _fill_rect...)
 replaced by NULL or by the cfb_ or fb_ generic
in the _ops struct ?

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

James Simmons wrote:

> I fixed those problems. It will compile but I can't test it to see if it
> works.

It didn't compile. Attached is the patch I used to get it to compile.
Didn't test it yet (box is at home, I'm at work :-)

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian
James Simmons wrote:

> I fixed those problems. It will compile but I can't test it to see if it
> works.

OK thanks a lot I'll try that and report.

BTW, would it be possible to become a linuxconsole develloper
so that the ruby-fied pm3fb would live on sourceforge ?

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

> The current (2.4.7) ruby won't compile on my Debian/PPC setup.

I fixed those problems. It will compile but I can't test it to see if it
works.

On Thu, Aug 02, 2001 at 08:30:42PM +0200, Vojtech Pavlik wrote:
> On Thu, Aug 02, 2001 at 11:13:21AM -0700, Charles Duffy wrote:
> > Being able to wake the mouse driver from more than one source (ie.
> > separately for /proc/input/devices and /dev/input/eventX) will require
> > a level of app restructuring in more than one case which I believe is
> > unnecessary and will reduce driver availability without good cause.
>=20
> Would there be a problem with
>=20
> 1) Opening and parsing /proc/input/devices.
> 1a) If no device is found either go to 1) if non-blocking is required
>     or select() on /proc/input/devices and then go to 1)
> 2) Opening the correct /proc/input/eventX
> 3) Read the event data
> 4) If -ENODEV received go to 1)

There are a few problems here:

1. It isn't possible to read from two devices simultaneously while
   still conforming to the single-source requirement. This is
   extremely useful when, for instance, a device has both a touchpanel
   and USB ports (ie. the Hitachi webpad).
2. Some mechanism will be required to allow the app to modify the fd
   in the select list used by the framework (in switching between
   steps 1 and 2 or 4).

I'm looking over the apps which will require modification. Qt/E
(thanks to its signal/slot notification) will be fairly
straightforward to support with the plan you propose; XFree86 also
looks straightforward (as much as it ever is). Microwindows, on the
other hand, will not be possible without architectural changes as it
requires a non-blocking mouse driver and provides no means of changing
the single fd which is select()ed on after open. Looping inside the
driver between 1 and 1a is as bad as a blocking select -- the point is
that the mouse driver's functions should be active very little time,
and only called when the single fd which it select()s on is ready.

> We can't sanely mix all event sources into one, because there are
> devices which generate lots of events and it'd be not a good idea in
> my opinion to feed all of them to the app.

So the app can use ioctl()s to decide what it does and doesn't wish to
hear. Perhaps the mixer initially provides nothing but attach and
detach events until the app adds additional sources via ioctl()s.

On Thu, Aug 02, 2001 at 11:13:21AM -0700, Charles Duffy wrote:

> Being able to wake the mouse driver from more than one source (ie.
> separately for /proc/input/devices and /dev/input/eventX) will require
> a level of app restructuring in more than one case which I believe is
> unnecessary and will reduce driver availability without good cause.

Would there be a problem with

1) Opening and parsing /proc/input/devices.
1a) If no device is found either go to 1) if non-blocking is required
    or select() on /proc/input/devices and then go to 1)
2) Opening the correct /proc/input/eventX
3) Read the event data
4) If -ENODEV received go to 1)

We can't sanely mix all event sources into one, because there are
devices which generate lots of events and it'd be not a good idea in my
opinion to feed all of them to the app.

-- 
Vojtech Pavlik
SuSE Labs

On Thu, Aug 02, 2001 at 10:07:16AM -0700, James Simmons wrote:
> > I'd rather not do this yet -- some applications don't support /dev/ts
> > properly, and it's extremely useful to be able to use either driver
> > with either kind of input device (in the case where one has a system
> > with both a mouse and a touchscreen attached).
>=20
> Which apps? Only X to my knowledge and a few other unknow apps use it.=20
> In the end apps should be ported over to use the event interface.=20

Are you asking which apps use mousedev? GtkFB, QtE, Nano-X
(Microwindows) and gpm, to name a few off the top of my head. Or are
you asking what uses Compaq's /dev/ts? X, Microwindows and QtE (though
it looks like it was patched in at the last minute there;
additionally, X's /dev/ts support is rather broken, having no support
for moving the cursor without the button depressed, though we should
be fixing that here soon).

I absolutely agree that apps should be ported to use the event
interface -- that's why I'm arguing for an event interface which is
easy to port to (ie. doesn't require any framework changes, which
listening on multiple fds does impose).

> > This will be less acute when a single interface is available which
> > provides applications with all available information (such as James's
> > suggestion of an evdev mixer which adds a field giving the minor
> > number of the evdev device correspending with the source).
>=20
> This is for /dev/shmiq support on IRIX platforms. BTW it is not a easy
> device to work with.

Ahh -- I misread you. 'Twould work rather well for evdev, though,
don't ya think?

Or do you have any alternate proposals?

Note that I won't be able to spend the time to write such an evdev
mixer and port the apps we support here (pretty much those listed
above, and X) to it at least until next month. When the time is
available, however, I'd be glad to do so; in the interm, we can come
to a design that everyone can agree to.

My basic requirement (which I'm loathe to negotiate on) is this:

- Hotplug and ready event notification must be available from one fd.
- It must not be necessary to perform any blocking calls (or a
  select() except with a zero timeout) on more than a single fd, this
  single fd presumably being that mentioned above.

Being able to wake the mouse driver from more than one source (ie.
separately for /proc/input/devices and /dev/input/eventX) will require
a level of app restructuring in more than one case which I believe is
unnecessary and will reduce driver availability without good cause.

> I'd rather not do this yet -- some applications don't support /dev/ts
> properly, and it's extremely useful to be able to use either driver
> with either kind of input device (in the case where one has a system
> with both a mouse and a touchscreen attached).

Which apps? Only X to my knowledge and a few other unknow apps use it. 
In the end apps should be ported over to use the event interface. 

> This will be less acute when a single interface is available which
> provides applications with all available information (such as James's
> suggestion of an evdev mixer which adds a field giving the minor
> number of the evdev device correspending with the source).

This is for /dev/shmiq support on IRIX platforms. BTW it is not a easy
device to work with.

Hello,

The current (2.4.7) ruby won't compile on my Debian/PPC setup.

Here's the error log:

#####
gcc -D__KERNEL__ -I/usr/src/linux-2.4.7-ruby/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -D__powerpc__ -fsigned-char
-msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring   
-c -o offb.o offb.c
offb.c:83: warning: initialization from incompatible pointer type
offb.c: In function `offb_init_fb':
offb.c:303: structure has no member named `cmap_adr'
offb.c:377: warning: passing arg 1 of `register_framebuffer' from
incompatible pointer type
offb.c:240: warning: unused variable `i'
offb.c: In function `offb_blank':
offb.c:419: `par' undeclared (first use in this function)
offb.c:419: (Each undeclared identifier is reported only once
offb.c:419: for each function it appears in.)
offb.c:427: warning: unreachable code at beginning of switch statement
offb.c:453: incompatible type for argument 1 of `fb_set_cmap'
offb.c: In function `offb_setcolreg':
offb.c:509: warning: dereferencing `void *' pointer
offb.c:509: invalid use of void expression
offb.c:514: warning: dereferencing `void *' pointer
offb.c:514: invalid use of void expression
#####

I can post .config if it's needed. I'm going to need a
screen (either offb or controlfb) before I can properly
port pm3fb (my old ELC is too slow for serious
programming :-)

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

allow: post

On Tue, Jul 31, 2001 at 10:31:08PM -0500, M. R. Brown wrote:
> * Sam Lantinga <sl...@de...> on Tue, Jul 31, 2001:
> 
> > > Looking through Joystick API I fail to notice any support for force
> > > feedback. I take that current API doesn't have any support. Now that 1.3 is
> > > coming is there going to be API support in it?
> > 
> > As far as I know force feedback is only available using the DirectInput API.
> > I'm hesitant to add something that only works on one platform.
> > 
> 
> IIRC, James Simmons and/or Vojtech Pavlik were working on an API for force
> feedback for ruby, codename for the linuxconsole project's 2.5 input tree
> (BTW some drivers do work in 2.4.x).  You can find the ruby source at
> http://sf.net/projects/linuxconsole-dev.
> 
> I don't know if they ever completed their work - hence the crosspost :).

Yes, it works with I-Force devices now.

> Linuxconsole-dev members, if you do reply to SDL, please include the line
> "allow: post" (sans quotes) as the first line of your reply (if you aren't
> already subscribed).  Thanks.

-- 
Vojtech Pavlik
SuSE Labs

allow: post

On Tue, 31 Jul 2001, M. R. Brown wrote:

> * Sam Lantinga <sl...@de...> on Tue, Jul 31, 2001:
> 
> > > Looking through Joystick API I fail to notice any support for force
> > > feedback. I take that current API doesn't have any support. Now that 1.3 is
> > > coming is there going to be API support in it?
> > 
> > As far as I know force feedback is only available using the DirectInput API.
> > I'm hesitant to add something that only works on one platform.
> > 
> 
> IIRC, James Simmons and/or Vojtech Pavlik were working on an API for force
> feedback for ruby, codename for the linuxconsole project's 2.5 input tree
> (BTW some drivers do work in 2.4.x).  You can find the ruby source at
> http://sf.net/projects/linuxconsole-dev.
> 
> I don't know if they ever completed their work - hence the crosspost :).

Vojtech and I are working on force feedback support for Linux.
The driver is still in development, but it's functionnal. Documentation is
available in ruby/linux/Documentation/input/ff.txt
Currently, only I-Force compatible devices are supported.

-- 
Johann Deneux
http://www.esil.univ-mrs.fr/~jdeneux/projects/

Hi.
I've solved a long standing problem with using an extended mouse over the 
ps/2 port on a thinkpad.  (search deja, I found bugreports dating back to 
1998, all unanswered)
I discovered there is a "smart" device called a trackpoint controller, that 
accumulates movement from both the trackpoints and the external mouse. 
Provided it understands the external mouse! (it only understand standard 
mice) A quick hack is disabling the trackpoint controller by sending 0xe2 
0x4e, but a more general solution would be to write a linux driver that 
autodetected a trackpoint controller with external mouse and disabled it.  In 
that way it would be transparant to userspace drivers.

The easiest for my would be writing it into pc_keyb.c but that's not 
appropiate. So where should I place the driver? 
If I want advanced functionality, where I instead demultiplexes the 
trackpoint and the external mouse into a /dev/psaux1 and -2, I need to take 
over the aux interrupthandler. Otherwise I can just speak through the 
standard psaux. 
And what of the new input-class, should all inputdevices eventually move over 
there, or just USB? 

regards
-Allan

* Sam Lantinga <sl...@de...> on Tue, Jul 31, 2001:

> > Looking through Joystick API I fail to notice any support for force
> > feedback. I take that current API doesn't have any support. Now that 1.3 is
> > coming is there going to be API support in it?
> 
> As far as I know force feedback is only available using the DirectInput API.
> I'm hesitant to add something that only works on one platform.
> 

IIRC, James Simmons and/or Vojtech Pavlik were working on an API for force
feedback for ruby, codename for the linuxconsole project's 2.5 input tree
(BTW some drivers do work in 2.4.x).  You can find the ruby source at
http://sf.net/projects/linuxconsole-dev.

I don't know if they ever completed their work - hence the crosspost :).

Linuxconsole-dev members, if you do reply to SDL, please include the line
"allow: post" (sans quotes) as the first line of your reply (if you aren't
already subscribed).  Thanks.

M. R.

> I don't like the way as well. I don't like having mousedev at all. But
> so far it was very useful. Perhaps we could somehow tell mousedev about
> the screen resolution when we're not in X? That would make it work
> nicely in console mode with eg. GPM.

This will not be easy. Their is also the case with embedded systems that
don't use a VT console. I run my ipaq using ruby only with a serial
console. 

> I agree that we should avoid oopses and thus the patch is OK, but still
> I think all drivers should provide min and max for the absolute axes.

I have to agree here. For the ipaq I basically read raw data from the
hardware to see what the maximum and minimum values reported back. For the
ipaq it is 1024x768 but yet the SA1100 framebuffer is at 240x320. 

On Mon, Jul 30, 2001 at 10:19:47PM +0200, Vojtech Pavlik wrote:
> On Mon, Jul 30, 2001 at 11:33:24AM -0700, Charles Duffy wrote:
> > There's quite a bit of software written (Qt/E, for one; Microwindows,
> > for another) which already has a mouse-handling architecture which
> > allows the mouse driver to open() a file, which is then returned by
> > the driver; the framework select()s on that file (among other things),
> > and calls the mouse event handler when select returns with the
> > appropriate fd.
>=20
> Unfortunately this probably won't help us with hotplugging.

If the only change is to add an extra field with the minor number,
then it won't. If, however, a means of notifying processes of
added/removed devices (ie. creation of a EV_CON w/ connection and
disconnection events, the latter only sent through the mixer), it will
do plenty of good.

> > Writing evdev drivers for this software would mean not only writing a
> > new driver module (a trivial task) but rearchitecting the framework to
> > allow drivers to own (and pass to the core) multiple fds, and
> > attempting to get these patches accepted by each of the projects in
> > question.
>=20
> Only if you want to use more than one mouse at a time.

=2E..or you want to have one device which, when opened, will *always*
get your mouse (whichever kind it may be). This is not an uncommon
case -- and being able to switch mice without restarting X (or
whatever the app may be) is most certainly useful.

> > Furthermore, there's no means of detecting disconnection/reconnection
> > -- another thing that an extended evdev mixer could (and, IMHO,
> > /should/) report.
>=20
> Disconnection is signalled by evdev by returning -ENODEV on read(). The
> process will be woken up on disconnect.

Quite right. But in Microwindows (for instance), disconnection of the
mouse will cause the system to die, without even calling the mouse
driver for its advice. One of the assumptions the system is based
around -- an assumption which is valid everywhere else -- is that mice
will *not* be hot-plugged, or that if they are the device will still
remain valid in the mean-time.

I'm not familiar with the behaviour of Qt/E or X in these cases, but
I'd be unsuprised were they similar.

> > Assuming that all evdev devices support USB is
> > faulty -- I personally have some that aren't (including some
> > non-hot-pluggable devices which may be rmmod'd on entry to powersaving
> > mode and re-insmod'd on restart; it's quite unuseful if applications
> > can't detect new minor numbers and such as a result of such things).
>=20
> How would you propose detecting new minor numbers? I'd suggest doing it
> the same way as USB does with new devices - read /proc/input/devices for
> an uptodate list, select() on the very same file to get notified of its
> changes.

If the evdev mixer is implemented inside the evdev module, it will
have access to the evdev_list, and thus the evdev struct including the
minor number.

As for /proc/input/devices, while the concept is great in theory, it
would vastly complicate the task of writing evdev-based drivers for
application software.

It will mean that the existing mouse interfaces (which
near-universally assume that an input driver, when it initializes,
will only need to be notified of events from one fd; that this fd will
never change; that when the file is closed on the other side, there's
no recovery possible) are insufficient, and that the userland
frameworks providing them will need to be rewritten (perhaps meaning a
rewrite for the other mouse drivers included in these packages as
well).

In short, making it necessary for a mouse driver to monitor more than
one file means /a whole lot more work/ for those of us writing evdev
drivers on the userspace end -- and that's not good for anyone.

On Mon, Jul 30, 2001 at 11:33:24AM -0700, Charles Duffy wrote:
> On Mon, Jul 30, 2001 at 09:19:53AM +0200, Vojtech Pavlik wrote:
> > On Sun, Jul 29, 2001 at 06:20:55PM -0700, Charles Duffy wrote:
> > > This will be less acute when a single interface is available which
> > > provides applications with all available information (such as
> > > James's suggestion of an evdev mixer which adds a field giving the
> > > minor number of the evdev device correspending with the source).
> > 
> > Do we really need an evdev mixer? Isn't it easier to just try to
> > open and read all the evdev devices?
> 
> No, it isn't.
> 
> There's quite a bit of software written (Qt/E, for one; Microwindows,
> for another) which already has a mouse-handling architecture which
> allows the mouse driver to open() a file, which is then returned by
> the driver; the framework select()s on that file (among other things),
> and calls the mouse event handler when select returns with the
> appropriate fd.

Unfortunately this probably won't help us with hotplugging.

> Writing evdev drivers for this software would mean not only writing a
> new driver module (a trivial task) but rearchitecting the framework to
> allow drivers to own (and pass to the core) multiple fds, and
> attempting to get these patches accepted by each of the projects in
> question.

Only if you want to use more than one mouse at a time.

> Furthermore, there's no means of detecting disconnection/reconnection
> -- another thing that an extended evdev mixer could (and, IMHO,
> /should/) report.

Disconnection is signalled by evdev by returning -ENODEV on read(). The
process will be woken up on disconnect.

> Assuming that all evdev devices support USB is
> faulty -- I personally have some that aren't (including some
> non-hot-pluggable devices which may be rmmod'd on entry to powersaving
> mode and re-insmod'd on restart; it's quite unuseful if applications
> can't detect new minor numbers and such as a result of such things).

How would you propose detecting new minor numbers? I'd suggest doing it
the same way as USB does with new devices - read /proc/input/devices for
an uptodate list, select() on the very same file to get notified of its
changes.

-- 
Vojtech Pavlik
SuSE Labs

On Mon, Jul 30, 2001 at 09:42:06AM -0700, James Simmons wrote:
> 
> > > This will be less acute when a single interface is available which
> > > provides applications with all available information (such as James's
> > > suggestion of an evdev mixer which adds a field giving the minor
> > > number of the evdev device correspending with the source).
> > 
> > Do we really need an evdev mixer? Isn't it easier to just try to open
> > and read all the evdev devices?
> 
> Actually the problem is hot plug. For the software at work I basically
> have a thread that runs so often to see if a new device is attached.
> This method really sucks. We really need away to know when a new device
> has attached. I remember you mentioned having something in proc for that. 
> Perhaps we should explore this path?

Yep. I'll try to create something today/tomorrow.

-- 
Vojtech Pavlik
SuSE Labs

On Mon, Jul 30, 2001 at 09:19:53AM +0200, Vojtech Pavlik wrote:
> On Sun, Jul 29, 2001 at 06:20:55PM -0700, Charles Duffy wrote:
> > This will be less acute when a single interface is available which
> > provides applications with all available information (such as
> > James's suggestion of an evdev mixer which adds a field giving the
> > minor number of the evdev device correspending with the source).
>=20
> Do we really need an evdev mixer? Isn't it easier to just try to
> open and read all the evdev devices?

No, it isn't.

There's quite a bit of software written (Qt/E, for one; Microwindows,
for another) which already has a mouse-handling architecture which
allows the mouse driver to open() a file, which is then returned by
the driver; the framework select()s on that file (among other things),
and calls the mouse event handler when select returns with the
appropriate fd.

Writing evdev drivers for this software would mean not only writing a
new driver module (a trivial task) but rearchitecting the framework to
allow drivers to own (and pass to the core) multiple fds, and
attempting to get these patches accepted by each of the projects in
question.

Furthermore, there's no means of detecting disconnection/reconnection
-- another thing that an extended evdev mixer could (and, IMHO,
/should/) report. Assuming that all evdev devices support USB is
faulty -- I personally have some that aren't (including some
non-hot-pluggable devices which may be rmmod'd on entry to powersaving
mode and re-insmod'd on restart; it's quite unuseful if applications
can't detect new minor numbers and such as a result of such things).

> > This will be less acute when a single interface is available which
> > provides applications with all available information (such as James's
> > suggestion of an evdev mixer which adds a field giving the minor
> > number of the evdev device correspending with the source).
> 
> Do we really need an evdev mixer? Isn't it easier to just try to open
> and read all the evdev devices?

Actually the problem is hot plug. For the software at work I basically
have a thread that runs so often to see if a new device is attached.
This method really sucks. We really need away to know when a new device
has attached. I remember you mentioned having something in proc for that. 
Perhaps we should explore this path?

On Sun, Jul 29, 2001 at 06:20:55PM -0700, Charles Duffy wrote:

> On Sun, Jul 29, 2001 at 11:00:08PM +0200, Vojtech Pavlik wrote:
> > By the way, now that we have tsdev, perhaps support for abs values
> > in mousedev could be dropped completely, because X will be able to
> > read even say USB tablets via the tsdev device as absolute values?
> 
> I'd rather not do this yet -- some applications don't support /dev/ts
> properly, and it's extremely useful to be able to use either driver
> with either kind of input device (in the case where one has a system
> with both a mouse and a touchscreen attached).
> 
> This will be less acute when a single interface is available which
> provides applications with all available information (such as James's
> suggestion of an evdev mixer which adds a field giving the minor
> number of the evdev device correspending with the source).

Do we really need an evdev mixer? Isn't it easier to just try to open
and read all the evdev devices?

-- 
Vojtech Pavlik
SuSE Labs

On Sun, Jul 29, 2001 at 11:00:08PM +0200, Vojtech Pavlik wrote:
> By the way, now that we have tsdev, perhaps support for abs values
> in mousedev could be dropped completely, because X will be able to
> read even say USB tablets via the tsdev device as absolute values?

I'd rather not do this yet -- some applications don't support /dev/ts
properly, and it's extremely useful to be able to use either driver
with either kind of input device (in the case where one has a system
with both a mouse and a touchscreen attached).

This will be less acute when a single interface is available which
provides applications with all available information (such as James's
suggestion of an evdev mixer which adds a field giving the minor
number of the evdev device correspending with the source).

On Sun, Jul 29, 2001 at 01:21:29PM -0700, Charles Duffy wrote:
> On Sun, Jul 29, 2001 at 08:31:38PM +0200, Vojtech Pavlik wrote:
> > On Tue, Jul 24, 2001 at 08:21:43PM -0700, Charles Duffy wrote:
> > > Thus, I'd like to have this be Correct Behaviour for an event handler.
> > > (Some changes are also needed to tsdev.c; I'd be glad to provide
> > > them).
> > 
> > I think much better would be letting mousedev know both the correct
> > screen and touchpanel resolution.
> 
> Yes, if the information is available. If it isn't, it makes sense for
> an event handler to attempt to function nevertheless rather than give
> up utterly.

I agree with the changes to mousedev (and/or tsdev) because they make it
more robust.

But this is *not* a reason to omit setting the absmin/absmax in the
touchscreen driver.

> It also doesn't make sense to require the device
> generating events to ask the user for numbers which aren't otherwise
> available to it if in most application those numbers will serve no
> purpose.

Yes. But it would definitely be nice if it could get the numbers from
the console subsystem - in many cases they are known. Namely on
handhelds.

By the way, now that we have tsdev, perhaps support for abs values in
mousedev could be dropped completely, because X will be able to read
even say USB tablets via the tsdev device as absolute values?

> Thus, while I agree that an event generator should be as strict as
> possible in what it generates -- providing resolution numbers if at
> all available -- an event handler should still be able to Do The Right
> Thing (or the closest possible approximation) if the numbers just
> aren't there.

It's good we agree perfectly then.

-- 
Vojtech Pavlik
SuSE Labs

2000	Jan	Feb	Mar (235)	Apr (30)	May (32)	Jun (86)	Jul (81)	Aug (108)	Sep (27)	Oct (22)	Nov (34)	Dec (10)
2001	Jan (78)	Feb (10)	Mar (81)	Apr (27)	May (13)	Jun (105)	Jul (78)	Aug (52)	Sep (59)	Oct (90)	Nov (127)	Dec (49)
2002	Jan (102)	Feb (72)	Mar (54)	Apr (98)	May (25)	Jun (23)	Jul (123)	Aug (14)	Sep (52)	Oct (65)	Nov (48)	Dec (48)
2003	Jan (22)	Feb (25)	Mar (29)	Apr (12)	May (16)	Jun (11)	Jul (20)	Aug (20)	Sep (43)	Oct (84)	Nov (98)	Dec (56)
2004	Jan (28)	Feb (39)	Mar (41)	Apr (28)	May (88)	Jun (17)	Jul (43)	Aug (57)	Sep (54)	Oct (42)	Nov (32)	Dec (58)
2005	Jan (80)	Feb (31)	Mar (65)	Apr (41)	May (20)	Jun (34)	Jul (62)	Aug (73)	Sep (81)	Oct (48)	Nov (57)	Dec (57)
2006	Jan (63)	Feb (24)	Mar (18)	Apr (9)	May (22)	Jun (29)	Jul (47)	Aug (11)	Sep	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec