[winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb

Zenny garbytrash at gmail.com
Mon Nov 16 15:50:36 GMT 2015


On 11/16/15, Zenny <garbytrash at gmail.com> wrote:
> On 11/16/15, Antoine Martin <antoine at nagafix.co.uk> wrote:
>>
>>>>> Please find some more updates:
>>>>>
>>>>> §1 If I use Xdummy with xpra (as described in the wiki) and try to
>>>>> capture with ffmpeg the virtual console at 4k while displaying the
>>>>> remote in 1080p, it categorically reports as of below and fails to
>>>>> capture:
>>>>>
>>>>> [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside
>>>>> the screen size 1920x1080
>>>>> :10: Invalid argument
>>>> That's expected: Xdummy supports RandR and we resize the server's
>>>> virtual screen to match the size of the client's screen.
>>> Actually I want the server's virtual screen to remain at the same 4K
>>> resolution while downsizing the one of the client's screen to say 1K
>>> (in order to save bandwidth and for other reasons if any).
>> That doesn't make sense: if you render at 4K and downscale the image to
>> about 1K, then it will be unreadable on the client. (16 times smaller)
>
> a bit confusing how come 4K (3840x2169) screen is 16 times smaller
> than 1K (1920x1080), 4 times, I guess. Oh I would have said Full HD
> instead of 1K (my mistake).
>
>> There are ways to achieve server-side scaling with the video encoders,
>> but that's meant to be used for saving bandwidth on video content and is
>> mostly done automagically.
>
> This is not what is happening. I want to capture in 4K from the
> virtual X fb server in the server while rendering in FullHD (1080) in
> the client's machine for interaction purpose.
>
>>>>>>>>>> I have tested here with Xdummy and that worked fine.
>>>>>>>>> Can you share your Xdummy command if different from the one in the
>>>>>>>>> wiki?
>>>>>>>> I am using the one that gets generated in the xpra.conf like so:
>>>>>>>>
>>>>>>>> export DISPLAY=:10
>>>>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR
>>>>>>>> +extension RENDER -auth $XAUTHORITY -logfile
>>>>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir
>>>>>>>> ${HOME}/.xpra/xorg.conf.d
>>>>>>>> -config /etc/xpra/xorg.conf $DISPLAY
>>>>>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' :
>>>>>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy
>>>>> Thanks for very useful pointer:
>>>>>
>>>>> But how to specify the screen resolution with xpra_Xdummy (as you have
>>>>> suggested as quoted below)? In my case I need 4K in the virtual x
>>>>> server in server and 1K in the client, fyi
>>>>>
>>>>> export DISPLAY=:10
>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR
>>>>> +extension RENDER -auth $XAUTHORITY -logfile
>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d
>>>>> -config /etc/xpra/xorg.conf $DISPLAY
>> Use xrandr to change the resolution.

How to make changes in the virtual X server with xrandr. It could be
possible with xrandr, however my requirement is 4K in the server while
displaying the same content in FullHD or lower in the clients. It is a
bit confusing how to use xrandr to get two different resolutions in
server and client! Would you mind elaborating?

>>>> UPDATE: I started an xpra instance with the above command, but no xpra
>>>> sessions are listed:
>>>>
>>>> $ xpra list
>>>> xpra initialization error:
>>>>   No xpra sessions found
>> Then the session did not start.
>> Check your server log file, which will probably tell you that the Xvfb
>> failed to start.
>>>>
>>>> The xpra_Xdummy command above displays following in the console:
>>>> http://hastebin.com/tudewavuxe.avrasm
>>> The relevant log is at:
>>>
>>> http://hastebin.com/miqaxajusa.vhdl
>> I've just tried it in an Ubuntu Trusty virtual machine and got the
>> dreaded message:
>> "xf86OpenConsole: cannot open /dev/tty0"
>> Different error, but the same result: as I expected, Xdummy does not
>> work on Ubuntu.
>
> That means Xdummy is ruled out in the Ubuntu's case. So rely on xvfb,
> Right?
>
> Wbr,
> /z
>
>
>>
>> Cheers
>> Antoine
>>
>



More information about the shifter-users mailing list