Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 409925 - virtualx.eclass: add support for xf86-video-dummy
Summary: virtualx.eclass: add support for xf86-video-dummy
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo X packagers
URL: http://lists.x.org/archives/xorg-deve...
Whiteboard:
Keywords:
Depends on: 425322
Blocks: 476942
  Show dependency tree
 
Reported: 2012-03-27 21:23 UTC by Chí-Thanh Christopher Nguyễn
Modified: 2019-02-28 05:59 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
xdummy.eclass (xdummy.eclass,5.42 KB, text/plain)
2013-05-17 13:19 UTC, Rick Harris
Details
x11vnc-0.9.13.ebuild needed by xdummy.eclass (x11vnc-0.9.13.ebuild,2.22 KB, text/plain)
2013-05-17 13:20 UTC, Rick Harris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chí-Thanh Christopher Nguyễn gentoo-dev 2012-03-27 21:23:07 UTC
Xvfb seemst to be on its way out per ${URL}.

Before an Xvfb-less xorg-server hits the tree, it would be good to add support to start a normal X server with a special xf86-video-dummy configuration instead of Xvfb.

Things that we need to investigate:
1. Are any features present in Xvfb but not in xf86-video-dummy which are used by ebuilds?
2. Currently we set `export SANDBOX_ON="0"' already, but can a full X server cause more badness (e.g. by probing hardware)?
3. Has an application running in xorg-server more ways to invite trouble (e.g. xhost) or consume system resources than one in Xvfb?

I understand that a mischievous process can already perform worse things, so only discuss risks from accidental snafu.
Comment 1 Rick Harris 2013-05-17 13:19:32 UTC
Created attachment 348514 [details]
xdummy.eclass

xdummy.eclass to use xf86-video-dummy
Comment 2 Rick Harris 2013-05-17 13:20:43 UTC
Created attachment 348516 [details]
x11vnc-0.9.13.ebuild needed by xdummy.eclass
Comment 3 Steve L 2013-07-21 14:38:43 UTC
Nice work, Rick.

One minor point, there are a couple of excess subshells in the eclass, no doubt historical:

if [[ -n ${XDUMMY} && -n ${XHOST} ]] && \
   ( [[ -z ${DISPLAY} ]] || ! (${XHOST} &>/dev/null) ); then
=>
   { [[ -z ${DISPLAY} ]] || ! (${XHOST} &>/dev/null); }; then

You don't need a semi-colon after ) there, but you would for any other command unless it were terminated with already with '&', eg if the two were swapped around, or it were: v=$(cmd ..); }; then..
In general, when using  } to terminate on the same line, use ; before it, unless the command was backgrounded, since the & is a terminator. (Sorry if this is old news.)

XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done; echo ${i})
=>
XDISPLAY=0
while [[ -f /tmp/.X${XDISPLAY}-lock ]]; do
   let ++XDISPLAY
done

More seriously: xdummyargs="-tmpdir "${WORKDIR}"" is borked; it actually stops quoting for the expansion of $WORKDIR, and then tacks on an empty string.

This is what bash arrays were designed for:
local xdummyargs=(-tmpdir "$WORKDIR")
..
${XDUMMY} :${XDISPLAY} "${xdummyargs[@]}"
or:
cmd=("$XDUMMY" ":$XDISPLAY" "${xdummyargs[@]}")
and run: "${cmd[@]}"
..since it happens in 3 places. Use "${cmd[*]}" not @ when printing.

The end of the function would be quicker as:
((retval == 0)) && return
die "${FUNCNAME}: the ${XDUMMY_COMMAND} failed."

I'd also be tempted to change that to:
die "${FUNCNAME}: failed: ${XDUMMY_COMMAND} $*"
..if it's permitted.
Comment 4 Mike Gilbert gentoo-dev 2013-07-21 16:19:14 UTC
I think a better solution might be to install the Xdummy script in a separate package; I don't think you need to pull in all of x11vnc just for one script.
Comment 5 Mike Gilbert gentoo-dev 2013-07-21 16:38:18 UTC
Actually, upon further review, that Xdummy script is really ugly. There has to be a better way.
Comment 6 Matt Turner gentoo-dev 2019-02-28 05:59:46 UTC
(In reply to Chí-Thanh Christopher Nguyễn from comment #0)
> Xvfb seemst to be on its way out per ${URL}.

That plan seems to have died. See https://lists.x.org/archives/xorg-devel/2016-June/050266.html