Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!pacific.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) Newsgroups: comp.windows.x Subject: Re: Multiple Screens and Pointer Tracking? Message-ID: <8909160351.AA01033@Larry.McRCIM.McGill.EDU> Date: 16 Sep 89 03:51:35 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 89 > I am currently working on a multiple screen server implementation and > have some questions on the best way to handle pointer tracking. I'm not sure there is a *the* best way. But to continue.... > My first assumption is that the desired behavior is to have it appear > to the user as if the two monitors are contiguous as the pointer > moves between them (i.e. as it moves off the left side of Screen 1, > it appears on the right side of Screen 0, and vice versa). That is one reasonable approach. But again, calling it *the* desired behavior seems somewhat dubious to me. > Given that, the real rub comes in deciding how the coordinate space > of the pointer maps to the display space. > My question is not so much how to implement this, but rather what is > appropriate interface? The way I see it, the following are possible: > 1) No interface. Screen 0 is always assumed to be at a fixed > orientation from Screen 1. Blech! > 2) Provide options such as "-top", "-bottom", "-left", or > "-right" to specify the orientation of Screen 1 relative to > Screen 0 at server startup. (But what about 3 screens...). > I'd be interested to hear from anyone else who's worked with/on a > multiple screen server or just has a strong opinion on the subject. The MIT sample server on a Sun cg4 display is a multiple-screen server. The cg4 has a two-color plane and a full-color plane. (It also has another one-bit plane, but this plane is simply used to select which of the other two planes is displayed, on a per-pixel basis.) The sample server treats the two-color plane as a StaticGray screen, which is not really right: it should be PseudoColor with two colors. Ideally, these would be used to support two different visuals on a single screen. However, the sample server made a different choice: two screens on the same monitor. (Which one is displayed? The one the pointer is currently in.) They chose to arrange the two screens so that moving off either the left or right edge of one screen switches to the other. Topologically speaking, they wrapped the screens around a cylinder. (I have on occasion had the sample server get confused into thinking *three* screens were available; in this case, the three screens are arranged edge-to-edge in a loop, so that if you keep moving the mouse left (or right) you just cycle through all three screens. I assume the same happens for four or more screens.) Since you have different monitors corresponding to the different screens, you probably don't want to do this. Ideally, you[$] would like to be able to place each screen anywhere on an infinite plane[%], and restrict the mouse to some subregion of this plane. (The subregion might be the union of the screens, or simply the bounding box of their union, or perhaps something else.) [$] Well, actually, this is what *I* would like to see.... [%] You probably want to forbid overlap, at least initially. I'm not sure how well the X model would deal with the pointer being inside windows on two different screens at once, and while I can think of other models that allow overlap, they all seem to me as though they'd be hairy to implement and confusing to use. What should the user interface to this look like? I can see several options. I would want the option of fully specifying everything: something like -placescreen 0 0 0 -placescreen 1 wd1 0 -placescreen 2 wd1+wd2 0 ie, -placescreen where the expressions can refer to the width and height of the various screens if necessary. (The pointer could then be restricted to the smallest rectangle enclosing all screens, or perhaps it simply could not move off a boundary at a point where there's no other screen for it to move onto, whatever.) Of course, you might also want to provide a simpler way of specifying things; perhaps something like `-placescreen 1 rightof 0'? (Just make sure it does something reasonable if the screens are different sizes :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu