RE: GII event system
Hi
I just got one device which will be not so good to drive with your
conception of dividing space and click data:
This is touch screen. I think you used bank machines or something like that
:)
Best Regards. Dmitry
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 22, 1999 3:05 AM
To: [EMAIL PROTECTED]
Subject: Re: GII event system
Hi !
1. Mouse is a human input device, as well as others pointing device.
Practically buttons are related to mouse position and usual human expects
reasonable button action right in place where he has clicked it.
Yes. This however does not mean, that the driver producing the "clicks" has
to know anything about the driver producing the moves.
This is why the moves and clicks are separate. Please note, that it is
possible to mix relative and absolute pointer events. A simple example of
that would be keyboard emulated mouse (which only makes sense as relative
events) on a absolute-mouse target like X.
What have we do with GII. Something like that collecting:
pmove1 abs
pbutton
pmove2 abs
will do
(pmove1.x +pmove2.x)/2 and the same for y.
??? What ?
I'll sketch how a LibGGI mouse handling routine for a system that expects to
work with absolute coordinates is intended to look like:
{
static int mousex,mousey;
...
ggiEventPoll(vis, emKey|emPointer, NULL);
events = ggiEventsQueued(vis, emKey|emPointer);
while (events--) {
ggiEventRead(vis, event, emKey|emPointer);
switch(event.any.type) {
case evPtrButtonPress:
switch(event.pbutton.button) {
case GII_PBUTTON_FIRST:
do_something_as_appropriate(mousex,mousey);
break;
case GII_PBUTTON_SECOND:
...
}
break;
case evPtrButtonRelease:
... if needed ...
break;
case evPtrAbsolute:
mousex = event.pmove.x;
mousey = event.pmove.y;
break;
case evPtrRelative:
mousex += event.pmove.x;
mousey += event.pmove.y;
break;
}
/* Constrain mouse in any case */
if (mousex 0) mousex = 0;
if (mousey 0) mousey = 0;
if (mousex xmax) mousex = xmax;
if (mousey ymax) mousey = ymax;
} /* while */
}
As you can see, this nicely symmetriyes the cases of abs and rel events.
Basically the same can be done for apps that expect relative events, though
those might get trouble on absolute input data when trying to "keep turning
left" or similar.
Was it good? It is no good, at least because gii client software is not
right place to do it.
To do what ? (pmove1.x +pmove2.x)/2 ? There is no reasonable place to do
such a calculation at all. To make sense at all, you would have to make a
weighted mean based on the time between the individual event's timestamps.
There is no assumption of something like a linear motion between points
between move events, and for sure no assumption, that the click happens in
the middle of that.
The expected behaviour is, that the above used mousex,mousey variables
express the correct position of the pointer, when a click comes in.
If the mouse was moved between the last move and the click, the driver is
expected to send another move and then the click to correctly position the
pointer before transmitting the click.
Why do I need to keep every pmove message until get
pbutton and pmove again? That is not pretty at least.
You don't. See above. In case that delivers incorrect results, we have a bug
in a driver or backend and need to fix the driver or flame the backend
authors.
I understand that it is my task to determinate correct click place in
case
of relative move messages and I do. But I really hope I will be able to
avoid mouse cursor software emulation(what I have done because of no
choice)
and to forget about relative messages for pointing device like mouse in
the
future when GGI will take care about hardware cursor.
GGI will never take away the information you get from the input device.
While we may provide a method to place a hardware sprite on the display,
thus allowing to easily make up a mouse pointer, this will not influence
the pointer data sent from the input device.
I repeat ones more I am discussing only about the case when cursor
generation is not my task.
I still do not get what cursor generation has to do with input handling.
There are some applications that would be pretty unhappy, if we converted
all input to absolute pointer events. Guess why the X target has the
relmouse mode ...
In the depth My question was why after calling poll(I call it with 0 time
delay) the queued function shows only one message we have inside of
queue but actually there are many (inside of some internal buffers).
If that is the case, this is a bug and should be fixed.
I think poll function really poll only one message for each message type
per one call, does not it?
No. It should check and queue all attached inputs, and all inputs
Re: Mesa-GGI was Re: ggimesa+multi problem
What makes a card primary? Slot position on the motherboard? Usually yes. Some BIOSes have at least the option to scan AGP first or PCI first. CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
Re: Vertical retrace
On Wed, Oct 20, 1999 at 03:46:42PM -0700, Jon M. Taylor wrote: On Wed, 20 Oct 1999, [iso-8859-1] Rubén wrote: On 1999/Oct/20, Brian S. Julin wrote: Basically there are two situations to worry about. One is trying to find the ray position from userspace when the process is running. The other is trying to get the scheduler to run the process promptly at a certain ray positions. I think there is an easy solution for the first thing. Why don't you share a flag variable between the kernel and the process, that becomes 1 at the vertical retrace and 0 when it finishes? It would be for programmers even more efficient than reading from the IO port directly (which is impossible under Linux, obviously). It could be managed in a similar way than the graphics context, couldn't it? I think that putting this flag in the context map is the way to go. The flag can be quickly toggled by the interrupt handler, and nothing else is necessary. This doesn't get around the scheduling Hz problem, but that is a separate issue anyway, and needs to be fixed for a lot more than just GGI. It'd be even better to increase a value every vblank so applications can find out if it has missed any frames, and also to make sure applications don't redraw more than once per frame. -- Niklas
Re: how to display 30 frames/second?
On Thu, Oct 21, 1999 at 11:28:12AM +0200, [EMAIL PROTECTED] wrote: Hi ! i have a yuyv-rgb routine that gives me 13 fps at 756x568. I'd like to have a look. I've written a bunch of those as well, and it seems hard to get them quick and correct at the same time. My quickest one uses a u,v lookup table and then does something like r=g=b=y; r,g,b+=table[u][v]; clamp(rgb);. the attached code is taken from xawdecode (http://freetv.notrix.de/ - linux) it consists of init_decode that initialisises the colortable and decode_halfframe that convertes the provided yuyv buffer into a rgb-buffer including downscaling (x and y). putline??.s provides the neccesary assembler-routines (x86-mmx) to convert and scale the line in x-direction. putline15.s is for 15bpp, putline16.s is for 16bpp. to compile putline.s you need NASM. CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED] thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(- yuyv.tgz
Re: Idea to (maybe) get libGGI included in Linux-distributions
Actualy I don't know how many of the distributions you follow but the current trend is for graphical installs. As a matter of fact I just installed a caldera 2.3 system and it is graphical only ie no fall back on text available. It uses X with the vga server. But your right a graphical ggi installer would be a clencher. As much as the unix world hates to admit even they are overly impressed with eye candy. The other cool thing would be the screensaver thing that is graphical on the consol. :) On Thu, 21 Oct 1999, Andreas Beck wrote: Hi ! I am actualy working on a ggi centric distrobution. So I would be greatly interestred in what projects spring up that use ggi. Well - a graphical install system, that pretty quickly after bootup jumps into a graphical frontend would be a kickass argument for this distribution ... Yes - it is surplus as hell to have a graphical install, but former Win users will love it. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] = - Bryan Patrick Coleman [EMAIL PROTECTED] http://www.uncg.edu/~bpcolema Triad Linux Users Group Octagram Linux [EMAIL PROTECTED]
Re: Idea to (maybe) get libGGI included in Linux-distributions
Bryan Patrick Coleman wrote: The other cool thing would be the screensaver thing that is graphical on the consol. :) When the first talk came about writing a screen saver my first thought was that he was going to say something about porting the X screen savers to GGI to run on the console (or what ever). That would be pretty cool. Some daemon that would just fire up a screen saver after in activity or when called directly for locking purposes. You wouldn't need special savers for X if you were running Xggi. Just a side note, it should support multi-head properly (if anyone is planning on writing such a daemon any time soon). Right now the stock kernel with the MDA second head only blanks the terminal that has focus. So my old, hand-me-down, burnt-in, mono-display gets more burnt-in (at least is isn't sufferering as a Novell print server anymore).
Re: Vertical retrace
On 1999/Oct/22, Niklas Höglund wrote: I think there is an easy solution for the first thing. Why don't you share a flag variable between the kernel and the process, that becomes 1 at the vertical retrace and 0 when it finishes? It would be for programmers even more efficient than reading from the IO port directly (which is impossible under Linux, obviously). It could be managed in a similar way than the graphics context, couldn't it? I think that putting this flag in the context map is the way to go. The flag can be quickly toggled by the interrupt handler, and nothing else is necessary. This doesn't get around the scheduling Hz problem, but that is a separate issue anyway, and needs to be fixed for a lot more than just GGI. It'd be even better to increase a value every vblank so applications can find out if it has missed any frames, and also to make sure applications don't redraw more than once per frame. I'm not agree, applications doesn't have to use the same refresh than the monitor. Your monitor can be refreshing at 100 Hz, and 50 frames per second is more than enough to see an animation smooth. And if you do this, some people would synchronize the applications in infinite loops testing this number, instead of using alarms (the right method, IMHO). Other reason is that a flag is tested much faster than a number (at least on intel). I think that the number isn't needed at all, your alarm system should figure out when a frame is losed (GGL does this way the frame skipping), and It may not worry about real card-monitor frames. -- _ /_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: Vertical retrace
On Fri, 22 Oct 1999, Brian S. Julin wrote: On Fri, 22 Oct 1999, [iso-8859-1] Rubén wrote: On 1999/Oct/22, Niklas Höglund wrote: It'd be even better to increase a value every vblank so applications can find out if it has missed any frames, and also to make sure applications don't redraw more than once per frame. I'm not agree, applications doesn't have to use the same refresh than the monitor. Your monitor can be refreshing at 100 Hz, and 50 frames per second is more than enough to see an animation smooth. And if you do this, some people would synchronize the applications in infinite loops testing this number, instead of using alarms (the right method, IMHO). I think an incrementing number is more flexible and leaves the application programmer more leeway. I see no reason why we could not have both. And we _should_ have both, since lots of hardware supports both. We have not yet even filled up one 4K intel page with context info yet. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
