Synergy (up to now the old synergy 1.3.2) is used at the Deskotheque
Project [1] at the Institute for Computer Graphics and Vision [2] at
Graz University of Technology [3].
Since we need to work simultaneously on big multi projector screens,
MPX [4] is just what we need. Two weeks ago I stumbled accross synergy
+. I ported my changes from the old 1.3.2 code synergy+ to work with
the new XInput 2 API of XServer 1.7 as part of my bachelor thesis.
Pretty much of the code needed to be changed since I had to add device
IDs to many interfaces, the protocol (I versioned it 1.4 for now) and
introduced a CDeviceManager class to handle per device properties
(coordinates, IDs, active client,..).
I hope my work is of any use to somebody outside the Deskotheuqe
project. I'm not quite finished and the code is still a bit messy, but
I guess I'll have to wait with releasing the code until I have my
grade.
> Synergy (up to now the old synergy 1.3.2) is used at the Deskotheque > Project [1] at the Institute for Computer Graphics and Vision [2] at > Graz University of Technology [3]. > Since we need to work simultaneously on big multi projector screens, > MPX [4] is just what we need. Two weeks ago I stumbled accross synergy > +. I ported my changes from the old 1.3.2 code synergy+ to work with > the new XInput 2 API of XServer 1.7 as part of my bachelor thesis. > Pretty much of the code needed to be changed since I had to add device > IDs to many interfaces, the protocol (I versioned it 1.4 for now) and > introduced a CDeviceManager class to handle per device properties > (coordinates, IDs, active client,..). > I hope my work is of any use to somebody outside the Deskotheuqe > project. I'm not quite finished and the code is still a bit messy, but > I guess I'll have to wait with releasing the code until I have my > grade.
That sounds like some really interesting work. I'm curious how it worked from an end-user perspective, like does the keyboard always just follow the "primary" cursor?
> Sorry you didn't get a reply, seems to have slipped through the net.
> Maybe if I create a branch for you, you could commit your source code. > It doesn't matter if it's messy.
> Nick
> On 24 September 2009 09:30, markd <dok...@icg.tugraz.at> wrote:
>> Hello !
>> Synergy (up to now the old synergy 1.3.2) is used at the Deskotheque >> Project [1] at the Institute for Computer Graphics and Vision [2] at >> Graz University of Technology [3]. >> Since we need to work simultaneously on big multi projector screens, >> MPX [4] is just what we need. Two weeks ago I stumbled accross synergy >> +. I ported my changes from the old 1.3.2 code synergy+ to work with >> the new XInput 2 API of XServer 1.7 as part of my bachelor thesis. >> Pretty much of the code needed to be changed since I had to add device >> IDs to many interfaces, the protocol (I versioned it 1.4 for now) and >> introduced a CDeviceManager class to handle per device properties >> (coordinates, IDs, active client,..). >> I hope my work is of any use to somebody outside the Deskotheuqe >> project. I'm not quite finished and the code is still a bit messy, but >> I guess I'll have to wait with releasing the code until I have my >> grade.
> Sorry you didn't get a reply, seems to have slipped through the net.
No harm done. I am busy anyway these days. So sorry for my delayed answer too.
> Maybe if I create a branch for you, you could commit your source code. > It doesn't matter if it's messy.
I'd be honoured to commit my work. I'll need some time to adapt my changes to the current code base (it has been dormant in my svn repo for some month now), so you don't need to hurry with the branch setup.
> That sounds like some really interesting work. I'm curious how it > worked from an end-user perspective, like does the keyboard always > just follow the "primary" cursor?
Nice to hear, that somebody is interested :)
There was not much emphasis on comfortable handling ;-) The device configuration has to be done by external tools (xinput at the time). Then synergy would read the device hierarchy at startup and use whatever it found. I thought about device hierarchy change events, but did not implement anything to react to them.
To further clarify things: With MPX, there is no real primary cursor. You can create master devices (pointer and kbd focus - they do come in pairs) and attach slave devices (hardware keyboard and mouse) to them as you wish. So you could have one mouse attached to the "foo pointer" and 17 keyboards to the corresponding "foo keyboard". Wherever you set the keyboard focus with the pointer you can type something with one of the keyboards.
The only real issue was/is that toolkits and window manager don't support the multiple foci and everything gets mixed up sometimes if two users want to work independently on one desktop (a common use case in the Deskotheque project).
On 7 September 2010 23:55, Mark Dokter <dok...@icg.tugraz.at> wrote:
> I'd be honoured to commit my work. I'll need some time to adapt my changes > to the current code base (it has been dormant in my svn repo for some month > now), so you don't need to hurry with the branch setup.
I've branched 1.3.2 for you, as I assume this is the version you modified. Please commit to:
After that, you should merge in the 1.3 branch (so you can test), then after this, we can merge in your branch into the 1.3 branch. Does that make sense?
Mark, We are using the old non plus version of Synergy 1.3.1 and MPX and we would be very interested in the work that you have done integrating MPX and Synergy. So has the MPX branch been merged into a Synergy release by Nick Bolten? If not, could we get a copy of your drop so maybe we can merge it into 1.3..1 or maybe get your 1.3.2 old synergy source tree? Regards, Hoser
On Thursday, September 24, 2009 4:30:59 AM UTC-4, markd wrote:
> Hello !
> Synergy (up to now the old synergy 1.3.2) is used at the Deskotheque > Project [1] at the Institute for Computer Graphics and Vision [2] at > Graz University of Technology [3]. > Since we need to work simultaneously on big multi projector screens, > MPX [4] is just what we need. Two weeks ago I stumbled accross synergy > +. I ported my changes from the old 1.3.2 code synergy+ to work with > the new XInput 2 API of XServer 1.7 as part of my bachelor thesis. > Pretty much of the code needed to be changed since I had to add device > IDs to many interfaces, the protocol (I versioned it 1.4 for now) and > introduced a CDeviceManager class to handle per device properties > (coordinates, IDs, active client,..). > I hope my work is of any use to somebody outside the Deskotheuqe > project. I'm not quite finished and the code is still a bit messy, but > I guess I'll have to wait with releasing the code until I have my > grade.
> We are using the old non plus version of Synergy 1.3.1 and MPX and we
> would be very interested in the work that you have done integrating MPX
> and Synergy. So has the MPX branch been merged into a Synergy release
> by Nick Bolten? If not, could we get a copy of your drop so maybe we
> can merge it into 1.3..1 or maybe get your 1.3.2 old synergy source tree?
I think the sourcecode I uploaded to the projects repository isn't even
available anymore (at least I didn't find it when I last checked).
I also did not check lately if my code got merged into synergy+ but I
guess not, since it was quite a big code change (passing around device
IDs everywhere in the source code...) and mpx isn't really useful for
the average user (ever tried handling a computer with more than one set
of input devices? I can tell you - it gets really confusing since you're
most likely used to just grab that keyboard/mouse in front of you).
After I finished my bachelor thesis I even did another project on the
subject and adjusted the windows code to make it compatible with
synergy+mpx. You'd not get multiple pointers on windows, but the thing
would behave like you just connected several mice locally).
I did the whole project with some version of synergy 1.4 though. I
started out with 1.3, but during my work 1.4 was released so I ported
everything over to the new version.
If synergy+mpx-1.4 would be useful to you I can see if I can dig that
out of our svn server as I haven't looked at it in quite a while now.
I'm a regular synergy user, using the stock version though since I have
no need for mpx on my workstation doing single user tasks =)
Thanks for the reply Mark, We cant seem to get your code from the MPX tree within the synergy svn repository as I think it has been removed? We too are using the old (non plus) version of synergy as it seems to work better for us on our CentOS/Red Hat servers/systems. In fact we tried to move to a version later than 1.3.1 but for some reason the synergy server would stop running on Red Hat based systems (a known bug) and we are not sure if this has been fixed yet. As for MPX, we are definitely using it since we have a three headed touch enabled workstation with only one keyboard device. Via MPX (xinput), we have created touch pointers for each USB touch device on each display surface. So in all we have 4 pointers enabled, a mouse pointer that can travel across all three surfaces, and a touch pointer for each of the three surfaces. We even went through the trouble of changing the cursor to distinguish the mouse pointer from the touch pointers as it can get confusing as to which pointer is which. What is also confusing is the fact that you may now have multiple windows that appear to have focus but it is what it is. Additionally one of our monitors is being controlled by a different server ( and remember we have only one keyboard) so that is where synergy comes into play for us. Our problem though is when the monitor controlled by the other server is touched, the focus is not transferred between the synergy client and server for keyboard entry since synergy doesn't really know about the touch device. So that is why we want to try your version to see if this will work for us. Again thanks for the reply and please let us know if we can get a copy of your 1.4 version that you may still have in your repository so maybe we can run some tests with it. R- Hoser
On Monday, July 30, 2012 7:11:45 PM UTC-4, markd wrote:
> On 07/30/2012 06:02 PM, Hoser wrote: > > Mark,
> Hi!
> > We are using the old non plus version of Synergy 1.3.1 and MPX and we > > would be very interested in the work that you have done integrating MPX > > and Synergy. So has the MPX branch been merged into a Synergy release > > by Nick Bolten? If not, could we get a copy of your drop so maybe we > > can merge it into 1.3..1 or maybe get your 1.3.2 old synergy source > tree?
> I think the sourcecode I uploaded to the projects repository isn't even > available anymore (at least I didn't find it when I last checked). > I also did not check lately if my code got merged into synergy+ but I > guess not, since it was quite a big code change (passing around device > IDs everywhere in the source code...) and mpx isn't really useful for > the average user (ever tried handling a computer with more than one set > of input devices? I can tell you - it gets really confusing since you're > most likely used to just grab that keyboard/mouse in front of you).
> After I finished my bachelor thesis I even did another project on the > subject and adjusted the windows code to make it compatible with > synergy+mpx. You'd not get multiple pointers on windows, but the thing > would behave like you just connected several mice locally).
> I did the whole project with some version of synergy 1.4 though. I > started out with 1.3, but during my work 1.4 was released so I ported > everything over to the new version.
> If synergy+mpx-1.4 would be useful to you I can see if I can dig that > out of our svn server as I haven't looked at it in quite a while now. > I'm a regular synergy user, using the stock version though since I have > no need for mpx on my workstation doing single user tasks =)
On 31 July 2012 00:11, Mark Dokter <dok...@icg.tugraz.at> wrote:
> I think the sourcecode I uploaded to the projects repository isn't even
> available anymore
Yeah, the trunk was getting so diverged from your mpx branch. I looked
at a diff, and it looked like there may have been some pitfalls, so
sadly it just collected dust. I decided that since it isn't being
used, I would delete it (but it's still in the history, so it's not
lost forever).
Do you think mpx would be a good candidate for a plugin?
On Tuesday, July 31, 2012 10:39:08 AM UTC-4, Nick Bolton wrote:
> Hi Mark,
> On 31 July 2012 00:11, Mark Dokter <dok...@icg.tugraz.at> wrote: > > I think the sourcecode I uploaded to the projects repository isn't even > > available anymore
> Yeah, the trunk was getting so diverged from your mpx branch. I looked > at a diff, and it looked like there may have been some pitfalls, so > sadly it just collected dust. I decided that since it isn't being > used, I would delete it (but it's still in the history, so it's not > lost forever).
> Do you think mpx would be a good candidate for a plugin?
Nick, Thank you very much for making the repository available to us. We got it to compile and the synergys and synergyc processes are running on their respective platforms. What's puzzling is why "markd" implementation hides the MPX touch pointers when the mouse moves over to the client. We have a two headed display on the server side (primary) and it took some doing to get the left touch courser over to the left side (monitor). We had to badly calibrate (relative mode) the device and send XI touch "drag" events over to it and once the pointer was on the screen we had to recalibrate the device (in absolute mode) such that the left touch pointer stays on the left screen. So when the primary screen is re-entered via the mouse, the left and center touch pointers reappear but both the touch pointers are now on the same "center" screen. We also wanted the XI touch events to cause keyboard and focus to go to the touched screen much like the mouse trackball does. We are trying to change the code however we haven't been successful yet.. Hopefully "markd" will perk up with some ideas? R- Hoser
On Tuesday, August 7, 2012 2:25:26 PM UTC-4, Nick Bolton wrote:
> On 7 August 2012 19:17, Hoser <g...@piasecki.name <javascript:>> wrote: > > We would simply like to get a copy of what Mark had posted for Synergy > MPX > > or get an updated version so we can test and see if it works for us.
> Nick,
> Thank you very much for making the repository available to us. We got
> it to compile and the synergys and synergyc processes are running on
> their respective platforms. What's puzzling is why "markd"
> implementation hides the MPX touch pointers when the mouse moves over to
> the client.
Hi there again!
You should have a version of synergy+mpx dated 03/2011 in your inbox now
*finally*
As I also wrote in that email: The local cursor hiding is done via
xfixes to not get irritated by a cursor moving on the local screen when
you move over to the remote screen. It's just two calls to
XFixes{Show,Hide}Cursor() which are quickly commented out. They don't do
you any good anyway since xfixes is still not mpx aware (correct me if
I'm wrong here).
> [...] We have a two headed display on the server side (primary)
> and it took some doing to get the left touch courser over to the left
> side (monitor). We had to badly calibrate (relative mode) the device
> and send XI touch "drag" events over to it and once the pointer was on
> the screen we had to recalibrate the device (in absolute mode) such
> that the left touch pointer stays on the left screen. So when the
> primary screen is re-entered via the mouse, the left and center touch
> pointers reappear but both the touch pointers are now on the same
> "center" screen. We also wanted the XI touch events to cause keyboard
> and focus to go to the touched screen much like the mouse trackball
> does. We are trying to change the code however we haven't been
> successful yet.. Hopefully "markd" will perk up with some ideas?
We've never used any touch devices or whatever extra touch functionality
is available in xwindows nowadays. I've used the relative movement
information from raw events in order to not have to calculate movement
deltas.
> Do you think mpx would be a good candidate for a plugin?
Without looking into the matter thoroughly I'd say nope.
Synergy events don't use device IDs which I pass around in synergy+mpx
all the time and keep track of them in a CDeviceManager class.
The network protocol wouldn't fit either because of the device IDs. But
that'd probably just be a matter of negociating the right protocol
version when connecting.
So without touching core synergy this isn't doable I guess.
Thanks for the replies Mark. After reading your paper/thesis which is very informative and well written, Section 5.3 describes as to why the master touch cursor disappears due to a limitation of the XFixes extension which performs the (Hide or Show) operation on all available pointers. So in our case when the mouse/trackball moves off of the primary screen we want the touch pointers to remain displayed on their respective screens (and we have modified the device cursor bitmaps so you can distinguish the mouse/trackball from the touch device pointers). So in order to keep the touch pointer displayed whenever the trackball enters/leaves the primary screen we removed the XFixes call as you had recommended, but we replaced it with a XDefineCursor call specifying the Virtual Core Pointer Device Number and either the createBlankCursor or the bit map image to be displayed (whichever case applies) for only the primary (track ball/virtual core pointer device) cursor. That way the touch pointers are left untouched and are always displayed. This seems to work OK for us. What remains for us now is that when the primary screen touch device is pressed we want the keyboard focus to go into the window underneath at the location touched and leave the trackball pointer where it is. I don't think this is exactly the same as the existing switchToScreen functionality because we just want keyboard input and not necessarily change the mouse device location/screen. So we may be breaking a Synergy paradigm here but touch pointers/devices never leave their respective screens and they can always be touched. We have actually added an XI2 extension event handler such that we know when an XIRawButtonPress event occurs for the touch device on the master screen via the CXWindowsScreen class but what work do we have to perform now to get keyboard events to go into the window where the touch was performed provided keyboard focus was previously going into a client window? Are we talking about adding new messages to the protocol or do you all have any ideas how this functionality can be implemented under the current synergy design/framework? Also we haven't figured out yet how to make the synergy client side touch device aware. Any ideas or design suggestion are welcomed.
On Tuesday, August 14, 2012 10:44:47 AM UTC-4, markd wrote:
> On 08/09/2012 11:15 PM, Hoser wrote: > > Nick, > > Thank you very much for making the repository available to us. We got > > it to compile and the synergys and synergyc processes are running on > > their respective platforms. What's puzzling is why "markd" > > implementation hides the MPX touch pointers when the mouse moves over to > > the client.
> Hi there again!
> You should have a version of synergy+mpx dated 03/2011 in your inbox now > *finally*
> As I also wrote in that email: The local cursor hiding is done via > xfixes to not get irritated by a cursor moving on the local screen when > you move over to the remote screen. It's just two calls to > XFixes{Show,Hide}Cursor() which are quickly commented out. They don't do > you any good anyway since xfixes is still not mpx aware (correct me if > I'm wrong here).
> > [...] We have a two headed display on the server side (primary) > > and it took some doing to get the left touch courser over to the left > > side (monitor). We had to badly calibrate (relative mode) the device > > and send XI touch "drag" events over to it and once the pointer was on > > the screen we had to recalibrate the device (in absolute mode) such > > that the left touch pointer stays on the left screen. So when the > > primary screen is re-entered via the mouse, the left and center touch > > pointers reappear but both the touch pointers are now on the same > > "center" screen. We also wanted the XI touch events to cause keyboard > > and focus to go to the touched screen much like the mouse trackball > > does. We are trying to change the code however we haven't been > > successful yet.. Hopefully "markd" will perk up with some ideas?
> We've never used any touch devices or whatever extra touch functionality > is available in xwindows nowadays. I've used the relative movement > information from raw events in order to not have to calculate movement > deltas.
