Ok, I fixed the bug.
Please see the attached patch (which is the last patch plus the
additional fixes).
I fixed it by adding a nego->flags variable to the NEGO structure that
stored the returned value from the server of
EXTENDED_CLIENT_DATA_SUPPORTED.
This is probably important for other things,
I came across this:
http://msdn.microsoft.com/en-us/library/dd305336(v=PROT.10).aspx
Can someone give me a hint as to where in the code to check the
EXTENDED_CLIENT_DATA_SUPPORTED flag?
Thanks,
-Gadi
On Thu, May 26, 2011 at 11:59 AM, Gideon Romm
wrote:
> I don't know if this is useful, but it
I recently discovered that the new multimonitor support causes the
client to crash entirely on a multimonitor system that connects to a
Windows 2003 server while specifying "-f" for fullscreen.
Can anyone confirm this bug?
-Gadi
On Wed, Jun 1, 2011 at 3:33 PM, Gideon Romm
wrote:
> FWIW,
>
> I t
FWIW,
I think that the syntax you last proposed is good, where:
-g WxH : dimensions of the Linux window
-D : hides the window decorations, if so desired
--screen WxH[+X][+Y] ... specifies the Windows screens (first screen
being primary)
Seems you could get about any combination of things that
> For me it is OK; this was my first idea when the first patch has been
> reported but then some discussion has been done about getting a free
> version of it too and it has stuck so I thought the general idea was
> to push those two together but for me it is best to get this one in
> asap.
OK, I
On Thu, May 26, 2011 at 20:42, Jay Sorg wrote:
>> Since you have the environemnt would you be willing to help to include
>> support for the xinerama free variant so we merge both?
>
> I have the environment too.
>
> If you don't mind Otavio, I'd like to get this in now and then work on
> the xiner
> Since you have the environemnt would you be willing to help to include
> support for the xinerama free variant so we merge both?
I have the environment too.
If you don't mind Otavio, I'd like to get this in now and then work on
the xinerama free variant because we have to do some discussion fir
On Thu, May 26, 2011 at 15:59, Gideon Romm wrote:
...
> This is the xinerama-dependent code and not the command line
> xinerama-free code discussed in this thread.
>
> Perhaps this code can be merged while the command line version is
> worked out? This version works great for my needs.
Since you
I don't know if this is useful, but it was to me.
I needed the multi-monitor support as Josh originally attached as a
diff. But, it did not patch against the latest git pull. So, I
reworked the code and created a git diff of just the same code he
submitted.
This is the xinerama-dependent code and
On Tue, Mar 22, 2011 at 5:22 AM, Jay Sorg wrote:
> I agree.
> If configure finds xinerama and -f is used then use all the screens
> like the patch.
>
Please use ac_arg_with or ac_arg_enable to allow manual control of
optional dependencies. Gentoo Linux thanks you. :)
> I think that removing the hard dependency on xinerama is a good idea,
> and I like being able to specify the options manually.
>
> I believe there is some value in being able to use xinerama if it's
> available, though. It just seems unfriendly to force the user to enter
> all the monitor configu
I think that removing the hard dependency on xinerama is a good idea,
and I like being able to specify the options manually.
I believe there is some value in being able to use xinerama if it's
available, though. It just seems unfriendly to force the user to enter
all the monitor configuration if w
>> I would like to propose that we add a command line option for this and
>> remove the xinerama dependency entirely.
>
> Any reason to dislike to xinerama version?
a few reasons
- Thinlinx has a device that does dual screen but no xinerama.
- What is you have 3 monitors in xinerama but you on
Hi Jay,
I would suggest a comma-separated list of monitors that looks a bit like the
-g WxH option:
--multi 0:1280x1024, 1:1280x1024
On Fri, Mar 18, 2011 at 3:35 AM, Jay Sorg wrote:
> > Maybe the first screen is always primary, and each screen after that is
> just in
> > order (i.e. screen is
On Fri, Mar 18, 2011 at 8:19 AM, Otavio Salvador wrote:
> On Fri, Mar 18, 2011 at 03:00, Jay Sorg wrote:
> > I would like to propose that we add a command line option for this and
> > remove the xinerama dependency entirely.
>
> Any reason to dislike to xinerama version?
>
> I don't disagree with
On Fri, Mar 18, 2011 at 03:00, Jay Sorg wrote:
> I would like to propose that we add a command line option for this and
> remove the xinerama dependency entirely.
Any reason to dislike to xinerama version?
I don't disagree with the option but curious about the reason to avoid
using Xinerama. Is
> Maybe the first screen is always primary, and each screen after that is just
> in
> order (i.e. screen is implied by the order of the arguments on the command
> line):
>
> xfreerdp -g 2560x1024 --screen=1280x1024 --screen=1280x1024+1280+0
Yea, OK.
Lets see if any other ideas come up, else I'll
On Fri, 18 Mar 2011 05:41:24 pm Jay Sorg wrote:
> >> xfreerdp -g 2560x1024 --multimon 2 0 0 1280 1024 1 1280 0 1280 1024 0
> >>
> >
> > Seems a bit hard on the eyes. Still not very good, but perhaps:
> > xfreerdp -g 2560x1024 --screen=0,1280x1024 --screen=1,1280x1024+1280+0
> >
>
> I like it bu
>> xfreerdp -g 2560x1024 --multimon 2 0 0 1280 1024 1 1280 0 1280 1024 0
> Seems a bit hard on the eyes. Still not very good, but perhaps:
> xfreerdp -g 2560x1024 --screen=0,1280x1024 --screen=1,1280x1024+1280+0
I like it but how do you set which one is primary?
Maybe screen 0 is always primary.
On Fri, 18 Mar 2011 05:00:11 pm Jay Sorg wrote:
> If you want to do two 1280x1024 monitors side by side.
>
> xfreerdp -g 2560x1024 --multimon 2 0 0 1280 1024 1 1280 0 1280 1024 0
Seems a bit hard on the eyes. Still not very good, but perhaps:
xfreerdp -g 2560x1024 --screen=0,1280x1024 --screen=1,
I would like to propose that we add a command line option for this and
remove the xinerama dependency entirely.
If you want to do two 1280x1024 monitors side by side.
xfreerdp -g 2560x1024 --multimon 2 0 0 1280 1024 1 1280 0 1280 1024 0
So it's like this
--multimon
...
Jay
On Sat, Feb 5, 2011 at 00:52, Josh Nisly wrote:
> Ok, I've updated the configure script to make the Xinerama dependency
> optional.
Please update it to current master and use git format-patch to send
it. So we can include it easily.
If you need any help with GIT ping me privately and I help you.
Ok, I've updated the configure script to make the Xinerama dependency
optional.
Also, I had tried numerous times to use negative offsets for the screens
without success, but I just tried it now, and it works perfectly. Oh well.
Here's an updated patch. Any objections?
On Fri, Feb 4, 2011 at 6:22
Hello Josh,
First I'd like to thank you for the work on this.
On Fri, Feb 4, 2011 at 03:37, Josh Nisly wrote:
...
> I'm using Xinerama under X11 to determine monitor position. Is this the best
> way to do it? Is it okay to depend on the Xinerama extension at compile
> time? (If it's not enabled,
With the introduction of Windows 7 Ultimate and Server 2008 R2, RDP has the
capability to truly use multiple monitors, communicating monitor information
to the server, so that taskbar position, Shift+StartKey window moving, etc
work as they would natively.
I've attached a patch which implements th
25 matches
Mail list logo
