Xpra: Ticket #2361: Xorg and Xvfb screen and dpi problem

---

Mon, 22 Jul 2019 03:30:30 GMT - Irony:

when i remove /etc/xpra/xorg.conf or change xpra_Xdummy to Xorg command, the server can not start

---

Mon, 22 Jul 2019 03:43:01 GMT - Antoine Martin: owner changed

• owner changed from Antoine Martin to Irony

Please see wiki/ReportingBugs to provide the details required. My guess is that you're not using xpra's repository and packages, and therefore not using a patched dummy driver.

when i remove /etc/xpra/xorg.conf or change xpra_Xdummy to Xorg command, the server can not start

That's expected. They're there for a reason.

---

Mon, 22 Jul 2019 04:37:29 GMT - Irony: attachment set

• attachment set to serverlog.txt

serverlog.txt

---

Mon, 22 Jul 2019 04:37:52 GMT - Irony: attachment set

• attachment set to xpraconfig.txt

xpraconfig.txt

---

Mon, 22 Jul 2019 04:39:06 GMT - Irony:

Xorg and Xvfb screen and dpi problem

By default, xpra use Xorg to create display, It's depend on xorg.conf and other conf files. but there have some problem in some os system. for example, Some software displays incorrect layout and very small fonts.

1. Xorg

xvfb_command = "xpra_Xdummy -dpi 96 -noreset +extension GLX +extension RANDR +extension RENDER -logfile ${XPRA_LOG_DIR}/Xorg.${DISPLAY}.log -config /etc/xpra/xorg.conf"

2. Xvfb

xvfb_command = "Xvfb -dpi 96 -noreset +extension GLX +extension Composite -auth $XAUTHORITY -screen 0 5760x2560x24+32"

1、System Info:

LSB Version:	:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.4.1708 (Core)
Release:	7.4.1708
Codename:	Core

2、xpra version

python2-xpra-client-2.5.2-0.r22875.el7_6.x86_64
ffmpeg-xpra-4.1.1-1.el7_6.x86_64
libvpx-xpra-1.8.0-1.el7_6.x86_64
x264-xpra-20190109-0.el7_6.x86_64
xpra-html5-2.5.2-0.r22875.el7_6.noarch
xpra-common-server-2.5.2-0.r22875.el7_6.noarch
xpra-common-2.5.2-0.r22875.el7_6.noarch
python2-pyopengl-3.1.1a1-10xpra1.el7_6.x86_64
xpra-2.5.2-0.r22875.el7_6.x86_64
libwebp-xpra-1.0.0-1.el7_6.x86_64
python2-rencode-1.0.6-1.xpra1.el7_6.x86_64
python2-xpra-server-2.5.2-0.r22875.el7_6.x86_64
pygtkglext-1.1.0-27.xpra3.el7_6.x86_64
xpra-common-client-2.5.2-0.r22875.el7_6.noarch
python2-xpra-2.5.2-0.r22875.el7_6.x86_64

3、xpra config

config file: https://www.xpra.org/trac/attachment/ticket/2361/xpraconfig.txt

4、start command and logs

xpra start --bind-tcp=0.0.0.0:10010 --start=/usr/bin/gnome-terminal --auth=file --password-file=./password.txt --no-daemon --html=on --dpi=96 --debug=screen

log file: https://www.xpra.org/trac/attachment/ticket/2361/serverlog.txt

---

Mon, 22 Jul 2019 09:44:14 GMT - Antoine Martin:

Please check which version of the dummy driver is installed:

$ rpm -qa | grep drv-dummy
xorg-x11-drv-dummy-0.3.8-1.xpra2.fc30.x86_64

How are you starting your application? Is it Java based? Can I use it to reproduce this bug?

FYI:

• you are not securing your tcp socket with auth, only the unix-domain socket. The recommended syntax is: tcp-auth=file:filename=./password.txt.
• html=on should be the same as html=auto, which is the default
• dpi=96 will bypass the client settings synchronization (the server will use 96 and ignore what the value supplied by the client - which may be different)

---

Mon, 22 Jul 2019 10:33:00 GMT - Irony: status changed; resolution set

• status changed from new to closed
• resolution set to fixed

first query

rpm -qa | grep drv-dummy
xorg-x11-drv-dummy-0.3.7-1.el7.x86_64

then I remove old system version and install xorg-x11-drv-dummy-0.3.8-1.xpra2.el7.x86_64

It's work ok

---

Sat, 23 Jan 2021 05:49:14 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2361