qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC,Draft] ui: add an embedded Barrier client


From: Laurent Vivier
Subject: Re: [Qemu-devel] [RFC,Draft] ui: add an embedded Barrier client
Date: Wed, 28 Aug 2019 10:13:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Hi,

Le 28/08/2019 à 08:11, Gerd Hoffmann a écrit :
>   Hi,
> 
>> For instance:
>>
>>   section: screens
>>       localhost:
>>           ...
>>       VM-1:
>>           ...
>>       end
>>
>>   section: links
>>       localhost:
>>           right = VM-1
>>       VM-1:
>>           left = localhost
>>   end
>>
>> Then on the QEMU command line:
>>
>>     ... -object input-barrier,id=barrie0,name=VM-1 ...
>>
>> When the mouse will move out of the screen of the local host on
>> the right, the mouse and the keyboard will be grabbed and all
>> related events will be send to the guest OS.
> 
> Put that into docs/ ?

Yes, I'll add more docs once the code is ready.

> 
>> +#define BARRIER_VERSION_MAJOR 1
>> +#define BARRIER_VERSION_MINOR 6
>> +
>> +enum cmdids {
>> +    MSG_CNoop,
>> +    MSG_CClose,
>> +    MSG_CEnter,
>> +    MSG_CLeave,
>> +    MSG_CClipboard,
>> +    MSG_CScreenSaver,
>> +    MSG_CResetOptions,
>> +    MSG_CInfoAck,
>> +    MSG_CKeepAlive,
>> +    MSG_DKeyDown,
>> +    MSG_DKeyRepeat,
>> +    MSG_DKeyUp,
>> +    MSG_DMouseDown,
>> +    MSG_DMouseUp,
>> +    MSG_DMouseMove,
>> +    MSG_DMouseRelMove,
>> +    MSG_DMouseWheel,
>> +    MSG_DClipboard,
>> +    MSG_DInfo,
>> +    MSG_DSetOptions,
>> +    MSG_DFileTransfer,
>> +    MSG_DDragInfo,
>> +    MSG_QInfo,
>> +    MSG_EIncompatible,
>> +    MSG_EBusy,
>> +    MSG_EUnknown,
>> +    MSG_EBad,
>> +    /* connection sequence */
>> +    MSG_Hello,
>> +    MSG_HelloBack,
>> +};
> 
> Put that into a barrier-protocol header file?

I agree.

>> +    case MSG_QInfo:
>> +        p = write_cmd(ib, p, MSG_DInfo);
>> +        p = write_short(ib, p, 0);    /* x origin */
>> +        p = write_short(ib, p, 0);    /* y origin */
>> +        p = write_short(ib, p, 1920); /* width */
>> +        p = write_short(ib, p, 1080); /* height */
> 
> Hmm.
> 
> This is the screen size I guess?  Which you don't know ...
> What this is used for?
> Should we maybe use INPUT_EVENT_ABS_MAX here?
> 

Yes, it's screen size but we can't use INPUT_EVENT_ABS_MAX.

In fact Barrier can manage more than 2 displays:

   0            x1           x2           x3

0  +------------+------------+------------+---
   |            |            |            |
   |  localhost |    VM-1    |   VM-2     |
   |            |            |            |
y1 +------------+------------+------------+---
   |            |            |            |
   | remotehost |            |            |
   |            |            |            |
y2 +------------+------------+------------+---
   |            |            |            |

So Barrier will send events to localhost while x(mouse) is between 0 and
x1, to VM-1 while it is between x1 and x2, and to VM-2 between x2 and
x3. So we need to know the size of the display to have x2.

Normally when the barrier client runs into an OS it intercepts the
screen resizing information and send them to the server. In our case we
cannot (for instance if we use a vfio display) but I plan to add
properties to the input-barrier object to provide the information at
least statically.

>> +    case MSG_DMouseMove:
>> +        qemu_input_queue_abs(NULL, INPUT_AXIS_X, msg.mousepos.x, 0, 1920);
>> +        qemu_input_queue_abs(NULL, INPUT_AXIS_Y, msg.mousepos.y, 0, 1080);
> 
> ... and here too of course.
> 
>> +    addr.type = SOCKET_ADDRESS_TYPE_INET;
>> +    addr.u.inet.host = g_strdup("localhost");
>> +    addr.u.inet.port = g_strdup("24800");
> 
> Does it make sens to allow connecting to other machines?
> Or will the barrier daemon run on every machine anyway?

The barrier server runs only on the machine with the mouse and the
keyboard. Other machines have normally the barrier client daemon to
inject the mouse and keyboard events in the OS.

But we can imagine to have a remote host with a VM inside we want to
access from our local host. So, yes, I think it makes sens to allow
connecting to other machine. I will add that too.

I will try to add a keyboard remapping as we have with VNC because it
doesn't work well with my french keyboard (AZERTY). Or perhaps I can use
the "button" id instead of the keyid but I don't now how to map the
value to a qcode.

Thanks,
Laurent




reply via email to

[Prev in Thread] Current Thread [Next in Thread]