Summary: | [usability] x11-servers/xorg-server ships with black background which makes debugging X hard | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Wojciech A. Koszek <wkoszek> |
Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | 0mp, crees, danfe, w.schwarzenfeld |
Priority: | --- | ||
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Wojciech A. Koszek
2018-05-04 08:42:53 UTC
(In reply to Wojciech A. Koszek from comment #0) You can start Xorg with the -retro option if you want to have the X pattern back: X -retro startx -- -retro Can we make this or other non-black option the default? (In reply to Wojciech A. Koszek from comment #2) I think that Wojciech's suggestion is actually a pretty good idea. It would troubleshooting easier for newcomers, wouldn't it? I agree, but this is a bit of an intrusive change for a port. How about we update the docs to point out the -retro option? I didn't know about it either! https://www.bayofrum.net/~crees/patches/patch-handbook-xorg-retro https://www.bayofrum.net/~crees/doc/en_US.ISO8859-1/books/handbook/x-config.html (In reply to Chris Rees from comment #4) > I agree, but this is a bit of an intrusive change for a port. Just was unpleasantly astonished by this myself and found this PR. Personally I'd rather have "retro" pattern left by default and never touched (in accordance to "don't try to fix what ain't broken" rule), but then we'd have to do something about the "-retro" option (e.g. remove this bogosity) and *that* already becomes intrusive. On the other hand, if upstream makes a stupid decision (and replacing traditional X pattern with black inconclusive blank vagueness is certainly stupid, if not idiotic) then we, downstream packagers, should correct it for the benefit of our end-users. If upstream had decided to use solid color, why not make it the same as your favourite bikeshed? Dark purple seems fine. :-) This way, "-retro" option would still behave as expected, requiring no intrusive changes to the port other than simple s/black/$somecolor/ one-line patch. Hm, I'm not sure that 'black' is chosen as a 'wallpaper', but to be honest I'm not massively averse to forcing the -retro option by default, I just feel a bit uncomfortable with such a significant OS dependent change. Unless you've found the code that chooses black? (In reply to Chris Rees from comment #6) > Hm, I'm not sure that 'black' is chosen as a 'wallpaper'... > Unless you've found the code that chooses black? I guess you're right, it's not that simple. Basically, the logic goes like this: > if (party_like_its_1989) { // -retro > MakeRootTile(pWin); > backFlag |= CWBackPixmap; > } > else { > pWin->backgroundState = BackgroundPixel; > if (whiteRoot) // -wr > pWin->background.pixel = pScreen->whitePixel; > else > pWin->background.pixel = pScreen->blackPixel; > backFlag |= CWBackPixel; > } So it's special "blackPixel" colormap entry, not simply "solid black". I guess we're better off properly documenting how users can select 1989-style (-retro) or solid white (-wr) backgrounds. Another option would be to look into how OpenBSD patches it, but I don't feel motivated enough. A commit references this bug: Author: crees Date: Wed Mar 25 10:57:06 UTC 2020 New revision: 54014 URL: https://svnweb.freebsd.org/changeset/doc/54014 Log: Document the use of '-retro' to actually get a visible background. PR: ports/227967 Changes: head/en_US.ISO8859-1/books/handbook/x11/chapter.xml Yeah, updating the docs seems the best idea. I worry about diverging so that the Xorg docs might not match! Thanks for the comments. |