On Thu, 6 Jun 2002 clock@xxxxxxxxxxxxxxxxxxxxxxxx wrote:
> Cau
>
> Je to pravda s tou delta? Nemelo by se to prepsat?
>
> ----- Forwarded message from eeprom@xxxxxxxxxx -----
>
> Delivered-To: clock@xxxxxxxxxxxxxxxxxxxxxxxx
> Delivered-To: links-list@xxxxxxxxxxxxxxxxxxxx
> Date: Wed, 5 Jun 2002 19:59:22 -0300 (BRT)
> From: eeprom@xxxxxxxxxx
> X-X-Sender: eeprom@xxxxxxxxxxxxxxx
> To: links-list@xxxxxxxxxxxxxxxxxxxx
> Subject: [links-list] Re: Links 2.0pre5: Mouse smooth
> In-Reply-To: <20020605072527.A193@xxxxxxxxxxxxxxxxx>
> X-Sender-IP: 200.193.157.240
> X-listar-version: Listar v0.129a
> Errors-To: links-list-bounce@xxxxxxxxxxxxxxxxxxxx
> X-original-sender: eeprom@xxxxxxxxxx
> Precedence: bulk
> Reply-To: links-list@xxxxxxxxxxxxxxxxxxxx
> X-list: links-list
> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.11
>
>
> Ok, as I can see you really don't know what a delta-value is. I will try
> to explain you what exactly a Delta-Value is.
>
> The GPM_EVENT structure comes with two kind of mouse coordinates. Absolute
> coordinates and Delta coordinates.
>
> ABSOLUTE
> Absolute is the exact value of the position of the mouse. So, if GPM says
> that the mouse is at position (2,3) you simply use this value in your
> program and draw a mouse cursor. The problem is that GPM is a console
> mouse interface and it's coordinates are the current character position on
> the screen. So, if you use text-mode of 80x25 then the ABSOLUTE value of
> GPM will only range between (0,0) and (79,24). And obviously you can't use
> this on a 1024x768 resolution framebuffer screen. That's why the cursor
> will never reach the edge if we use Absolute coordinates.
>
> DELTA
> This is where the Delta-value comes in. The Delta-value is NOT the current
> cursor position of the mouse, but it is the movement wich the mouse has
> done since the last information request. So, if your mouse is at position
> (2,3) and you move the mouse smoothly upward, then on every information
> request GPM will return a Delta-value of (0,-1). X is zero because you are
> not moving the mouse horizontally, just vertically. If you move your mouse
> downward faster, the Delta-value will get (0,2) or maybe (0,3) depending
> on how sensitive GPM was configured to react.
>
> And now that you know that GPM returns to us the MOVEMENT wich the mouse
> has done, we don't need GPM to tell us where the mouse cursor is at the
> current time. We just keep track of the movement (delta) values and
> increment this values to our mouse_x and mouse_y variables, so we just
> ignore the console position of the mouse, we just check the movement.
>
> This is where the acceleration variable comes in. We multiply every
> movement wich was done by a certain number, making this movement larger.
> If we multiply the delta-value by 8, then the MINIMUM movement wich we can
> reach is a huge and ugly 8 pixel jump. Don't matter how smooth you move
> the mouse, because when GPM says that the movement was 1 pixel, then the
> multiplication of 8 will do 1*8 and we get a huge 8 pixel jump. So, we
> multiply it by something like 2 or 3 it's up to you, and that's why I want
> an acceleration variable instead of a static multiplication value.
>
> Ok, let's say that you have set the acceleration value to 1. This menas
> that you are now able to move the mouse 1 pixel at the time over the
> screen. But you use a resolution of 1024x768 and you have to move the
> mouse too much to cross the screen with the cursor? Ok, this is called
> SENSITIVITY and is easely adjusted at GPM. So you simply set your GPM
> sensitivity higher and get a VERY-COOL 1-Pixel movement of the mouse equal
> to the one of XFree86 or Windows.
>
> The problem now is that it seems that Mikulas is not even trying to make
> this mouse work properly under GPM and just continues to blame the GPM
> Development Team for this 'bad' programming interface. But I just have one
> thing to tell about this:
> I use the GPM driver on XFree86 and it works great with a cool and smooth
> and very sensitive 1 pixel movement, just like Windows.
So fix it yourself if you know how :)
Again, see this code inside gpm:
if (!(m_type)->absolute) {
fine_dx+=event->dx; fine_dy+=event->dy;
event->dx=fine_dx/opt_scale; event->dy=fine_dy/opt_scaley;
fine_dx %= opt_scale; fine_dy %= opt_scaley;
}
/* up and down, up and down, ... who does a do..while(0) loop ???
and then makes a break into it... argh ! */
if (!event->dx && !event->dy && (event->buttons==oldB))
do { /* so to break */
static long awaketime;
/*
* Ret information also if never happens, but enough time has
elapsed.
* Note: return 1 will segfault due to missing event->vc; FIXME!
*/
if (time(NULL)<=awaketime) return 0;
awaketime=time(NULL)+1;
break;
} while (0);
/*....................................... fill missing fields */
event->x+=event->dx, event->y+=event->dy;
... you see. At top of this code, event->dx contains relative mouse
movement in pixels. This is what we need. Then it is divided by opt_scale
-- the fine information about mouse movement is LOST,LOST,LOST and no one
sees it again.
You can: set multiply constant in framebuffer driver to 1 -- this means
that mouse will move smoothly but in a speed 1-char-on-screen ~
1-pixel-in-links -- that is, it will be 8 times slower and unuseable.
You can: set opt_scale in gpm to 1 -- this will fix the problem and you
will be able to move mouse smooth in links, however it will mean, that the
mouse will be unuseable fast in text mode (1 pixel movement will be
interpreted as 1 char movement)
Any other solutions how to use gpm in graphical programs?
Mikulas