On Sat, Jul 27, 2019 at 07:55:57PM +0000, DJ Lucas via blfs-dev wrote:
On 7/25/2019 12:26 PM, Ken Moffat via blfs-dev wrote:
The gentoo thread (from last year) which I was reading suggested that
startx, but also DEs (depending on the driver, intel was ok,
modesetting was not) were broken at that time.
Possibly
https://forums.gentoo.org/viewtopic-t-1092792-start-0.html
or
https://forums.gentoo.org/viewtopic-t-1088682-start-50.html
?
No, it was something else (or maybe a link from yet another thread
there), after searching for the initial error message and ignoring
very old debian messages!
But apparently some people have been using recent versions of the
book on desktops without this problem.
Yes, I'm one of those people. :-) I believe the above might be outdated. I
am using an older ATI card (I don't game, so $25-30 bargain buy for all of
mine, though I just realized that I still have the kernel parameter
amdgpu.si_support=1, though I now forget exactly why it was put in there):
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Cedar [Radeon HD 5000/6000/7350/8350 Series]
I don't game either, and I prefer low-power video cards (and until
recently vga connectors - still got to sort out monitor and kvm
changes before I think about a new desktop).
I was going to say that Cedar was 'evergreen' and supported by the
ATI driver, but I now see that the 7350 is Southern Islands - that
kernel parameter is to enable southern islands support in the amdgpu
driver. My A10 Kaveri APU (now retired - too slow, no L3 cache -
but was used briefly to confirm the HDMI input on a monitor was
working) could supposedly be used for that, but was reputed to not
work on vga (confirmed, but for me it didn't work on hdmi either).
Having never experienced the issue, I am not fully versed in the topic, but
in X log I have (forgive the root prompt, I'm currently chrooted):
root@lfsdt1 [ /sources/temp ]# grep modesetting /var/log/Xorg.0.log
[ 196.493] (==) Matched modesetting as autoconfigured driver 2
[ 196.513] (II) LoadModule: "modesetting"
[ 196.513] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 196.526] (II) Module modesetting: vendor="X.Org Foundation"
[ 196.528] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 196.532] (II) [KMS] Kernel modesetting enabled.
[ 196.532] (WW) Falling back to old probe method for modesetting
Interesting, modesetting certainly loaded, but you've trimmed the
dozens/hundreds/thousands of other lines so I can't see if X is
actually using modesetting, or after testing all possible drivers
used something with a higher priority, i.e. amdgpu (or radeon) ?
This is from RL3 with a newly created user who has no group membership and
no suid X binary (I do have the suid wrapper). I just can't figure out what
is different for me. Bruce's proposed build order (elsewhere in the thread)
looks a lot more similar to mine than his previous ones, but even looking at
his previous build order, I couldn't see anything (after fixing my previous
elogind dependency for xtrans). I mean, we've been building without suid
binary on systemd for some time, and never had issues AFAIK. So for the
moment, I'm just at a loss as to why it works for some but not all. I'll
plan on buying some different hardware in the second week of August and
revisiting it at that time.
For now, I'm working on the bootscripts. Some changes are required in the
standard boot order from the Makefile.
--DJ
This is useful information, but I'm still a long way from building
an up to date system, so for the moment I can't say if dropping the
suid setting will work on any of my machines.
