Dear Marc-André,
On Sonntag, 28. April 2013 16:41:43 Marc-André Moreau wrote:
> Hi Hans-Peter,
>
> Thanks for your contribution. I've started integrating bits from it, and
> I'm trying to think of the best way to get this done cleanly.
Cool.
> From the code
> I have working here, you've modified the multimon detection logic and
> extended the size option to get a desktop position.
Yes, with that code in place, we will get maximum flexibility in a minimum
invasive way.
> Here's what I'd like to do to:
>
> Add an option to list detected screens, and provide a command for passing
> in an array of displays to use.
>
> Let's say we could list the monitors like this (the following config
> matches my dual full-hd monitor setup)
>
> /monitor-list
> [0] 1920x1080 +0+0 *
> [1] 1920x1080 +1920+0
>
> We could then specify monitor settings like this:
>
> /monitors:0,1
> /monitors:1920x1080+0+0,1920x1080+1920+0
>
> /monitors:1
> /monitors:1920x1080+1920+0
I tried that approach already (in fact, it was my first attempt to tackle the
problem). Unfortunately, there's a big can of worm hidden behind the scenes,
because, it's going to be hard to determine the correct rectangle of all
screens, given that they can organize in arbitrary ways, orders and sizes.
Imagine a setup of four screens
+------+------+
|1 |2 |
| | |
+------+------+
|3 |4 |
+----+ |
| |
+--------+
which is perfectly possible, but it *will* result in complex calculations.
I avoided them by letting X to determine the maximum desktop, and just make
sure, the provided rectangle is in bounds.
For your examples, you can use /size:3840x1080 and /size:1920x1080+1920+0.
Even /workarea would work, given your task bar is 55px height at the bottom,
it would use /size:3840x1025+0+0. These values will be those most commonly
used for such a setup anyway.
> By default fullscreen shouldn't take all screens like it currently does, it
> is very annoying. We should enable it with /multimon for true multimon, and
> also support /span for the span mode.
Respecting the /multimon switch in that way for fullscreen is going to be
easy. I can provide that. BTW, what would the /span switch do exactly?
> With the following suggestions we'd
> be able to get complex multi-monitor setups working well. When going
> fullscreen without /multimon we can simply default to going fullscreen on
> the current screen, not all of them.
Okay, that sounds reasonable, and I can do that easily. With the /monitor
switch I'm much more reluctant to get this right. On the other hand, with my
current patches, all possible scenarios are already possible. Hence, I tend to
believe, that it's a step in the right direction and a good base for any
higher level options. If you would supply an arbitrary rectangle from the
pathological scenario above, my code would determine the correct monitor data.
> What do you think?
I'm not sure, if specifying the physical monitor organization buys us anything
on top of what can be archived already. OTOH, I fear the possibly complex
relationship of physical monitors to desktop appearance to virtual multimon
setup. Correlation of the physical to the virtual monitor setup is what we
will have to get right, especially, when it comes to setups with more then 2
monitors, and non "full" fullscreen modes, as those that I primarily address
with my patches. The terminal host will be confused, if the given resolution
does not match the monitor organization.
Pete
> On Sat, Apr 27, 2013 at 11:01 AM, Hans-Peter Jansen <h...@urpla.net> wrote:
> > On Freitag, 26. April 2013 18:11:57 Hans-Peter Jansen wrote:
> > > Dear Marc-Andre, dear RDP-People,
> > >
> > > this is an astonishing project, with so much high quality code, a nice
> >
> > build
> >
> > > environment, impressing progress, where I wonder, why it is so silent on
> > > any communication channel. Hmm.
> > >
> > > Anyway, here's a proposed contribution to your project.
> > >
> > > A few words on my environment: I'm responsible for a diskless linux
> >
> > desktop
> >
> > > setup (fat clients) in a transportation firm. All relevant desktops run
> >
> > on
> >
> > > 24" screens (1920x1200), with up to three of them resulting in a
> >
> > 5760x1200
> >
> > > desktop, exhausting the horizontal RDP limit of 4096... Oh, well. Let's
> > > wait for RDP 8.0 in Windows 9, raising it to .. 8192, I bet(!).
> >
> > Okay, this is not correct. It looks like only rdesktop does suffer from
> > this
> > limitation, but not xfreedrp:
> >
> > DBG_X11 xf_detect_monitors (96): desktop: 5760x1200+0+0 (max: 5760x1200)
> > DBG_X11 xf_detect_monitors (137): vscreen[0]: 1920x1200+0+0 (primary)
> > DBG_X11 xf_detect_monitors (137): vscreen[1]: 1920x1200+1920+0
> > DBG_X11 xf_detect_monitors (137): vscreen[2]: 1920x1200+3840+0
> > DBG_X11 xf_detect_monitors (146): area: 5760x1200+0+0
> > DBG_X11 xf_detect_monitors (179): monitor[0]: 1920x1200+0+0 (primary)
> > DBG_X11 xf_detect_monitors (179): monitor[1]: 1920x1200+1920+0
> > DBG_X11 xf_detect_monitors (179): monitor[2]: 1920x1200+3840+0
> >
> > as well as /workarea:
> >
> > DBG_X11 xf_detect_monitors (96): desktop: 5760x1153+0+0 (max: 5760x1153)
> > DBG_X11 xf_detect_monitors (137): vscreen[0]: 1920x1200+0+0 (primary)
> > DBG_X11 xf_detect_monitors (137): vscreen[1]: 1920x1200+1920+0
> > DBG_X11 xf_detect_monitors (137): vscreen[2]: 1920x1200+3840+0
> > DBG_X11 xf_detect_monitors (146): area: 5760x1153+0+0
> > DBG_X11 xf_detect_monitors (179): monitor[0]: 1920x1153+0+0 (primary)
> > DBG_X11 xf_detect_monitors (179): monitor[1]: 1920x1153+1920+0
> > DBG_X11 xf_detect_monitors (179): monitor[2]: 1920x1153+3840+0
> >
> > I'm really sorry about spreading silly FUD here. Please beg my pardon.
> >
> > FWIW, the current git incl. my patches is readily available for openSUSE
> >
> > here:
> > http://download.opensuse.org/repositories/home:/frispete:/RemoteDesktop
> >
> > Package: FreeRDP
> >
> > Let me know, if you miss a SUSE distribution here. Get an overview here:
> >
> >
> > https://build.opensuse.org/project/monitor?project=home%3Afrispete%3ARemot
> > eDesktop
> >
> > Comments, flames, etc. welcome.
> >
> > Cheers,
> > Pete
> >
> >
> > --------------------------------------------------------------------------
> > ---- Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> > service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> > _______________________________________________
> > Freerdp-devel mailing list
> > Freerdp-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freerdp-devel
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel
