Re: [Xen-devel] Re: PVFB wheel events (z-axis)

[Pat Campbell <plc@xxxxxxxxxx>]

Markus Armbruster wrote:
> Pat Campbell <plc@xxxxxxxxxx> writes:
>
>   
>> Markus Armbruster wrote:
>>     
>>> I got questions on this changeset:
>>>
>>>     changeset:   354:c3ff0b26f664
>>>     date:        Mon Dec 10 13:52:47 2007 +0000
>>>
>>>     Decode mouse event packet dz value and passes it as a wheel event into
>>>     the input stream.
>>>
>>>     Signed-off-by: Pat Campbell <plc@xxxxxxxxxx>
>>>
>>>     diff -r 7232a025140f -r c3ff0b26f664 drivers/xen/fbfront/xenkbd.c
>>>     --- a/drivers/xen/fbfront/xenkbd.c      Mon Dec 10 13:51:57 2007 +0000
>>>     +++ b/drivers/xen/fbfront/xenkbd.c      Mon Dec 10 13:52:47 2007 +0000
>>>     @@ -64,8 +64,13 @@ static irqreturn_t input_handler(int rq,
>>>                     dev = info->ptr;
>>>                     switch (event->type) {
>>>                     case XENKBD_TYPE_MOTION:
>>>     -                       input_report_rel(dev, REL_X, 
>>> event->motion.rel_x);
>>>     -                       input_report_rel(dev, REL_Y, 
>>> event->motion.rel_y);
>>>     +                       if ( event->motion.rel_z == 1 || 
>>> event->motion.rel_z == -1 ) {
>>>     +                               input_report_rel(dev, REL_WHEEL, 0 - 
>>> event->motion.rel_z);
>>>     +                       }           
>>>     +                       else {
>>>     +                               input_report_rel(dev, REL_X, 
>>> event->motion.rel_x);
>>>     +                               input_report_rel(dev, REL_Y, 
>>> event->motion.rel_y);
>>>     +                       }
>>>
>>> I don't understand the conditional.  Why is rel_z to be used *only*
>>> when it's 1 or -1, and why are rel_x and rel_y to be used *only* when
>>> rel_z isn't?  That sure is a weird protocol, and it isn't documented
>>> anywhere...
>>>   
>>>       
>> In my testing I never saw a case where the rel_x and rel_y were not zero
>> or the abs_x and abs_y changed when a  z event came thru.   A small
>> attempt to not flood the input stream with redundant data. 
>>     
>
> Assuming conditions you observed in your tests will hold elsehwere in
> space or time is calling for trouble :)
>
>   
>> Probably for clarity should have been:  (same for the abs case)
>>    if (event->motion.rel_z != 0)
>>        input_report_rel(dev, REL_WHEEL, 0 - event->motion.rel_z);
>>    input_report_rel(dev, REL_X, event->motion.rel_x);
>>    input_report_rel(dev, REL_Y, event->motion.rel_y);
>>     
>
> Why use REL_WHEEL and not REL_Z?
>   
Same answer as below, Xorg 6.9 does not decode REL_Z.  Xorg.7.3 handles
REL_Z and REL_WHEEL as the same.
> Why suppress zero Z-axis motion, but not X/Y-axis?
>
>   
Hmm.   Delving back into X
   Xorg 6.9
          case REL_WHEEL:
                if (value > 0)
                    PostButtonClicks(pInfo, wheel_up_button, value);
                if (value < 0)
                    PostButtonClicks(pInfo, wheel_down_button, -value);
                break;
    Xorg 7.3
              Just sends the value up, gets ignored later

I guess I saw that sending a '0' for REL_WHEEL was a waste of time and
decided to filtered it out.   Also not really necessary if it makes the
code easier to understand.  

>>>                             break;
>>>                     case XENKBD_TYPE_KEY:
>>>                             dev = NULL;
>>>     @@ -81,8 +86,13 @@ static irqreturn_t input_handler(int rq,
>>>                                            event->key.keycode);
>>>                             break;
>>>                     case XENKBD_TYPE_POS:
>>>     -                       input_report_abs(dev, ABS_X, event->pos.abs_x);
>>>     -                       input_report_abs(dev, ABS_Y, event->pos.abs_y);
>>>     +                       if ( event->pos.abs_z == 1 || event->pos.abs_z 
>>> == -1 ) {
>>>     +                               input_report_rel(dev, REL_WHEEL, 0 - 
>>> event->pos.abs_z);
>>>     +                       }
>>>     +                       else {
>>>     +                               input_report_abs(dev, ABS_X, 
>>> event->pos.abs_x);
>>>     +                               input_report_abs(dev, ABS_Y, 
>>> event->pos.abs_y);
>>>     +                       }
>>>
>>> And why isn't this using REL_ABS?
>>>   
>>>       
>> I assume you meant to ask why not ABS_WHEEL.  Xorg 6.9 evdev driver does
>>     
>
> Yes.
>
>   
>> not decode ABS_WHEEL.  Xorg 7.3 decodes  both REL and ABS WHEEL but
>> ABS_WHEEL requires extra xorg.conf input options.   We get greater
>> coverage by using REL_WHEEL and reduce the need to edit  xorg.conf.
>>     
>
> Okay, that's fair.
>   
> [...]
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>   


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel