[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-xorg
Subject: Re: X11 Xserver startup problem on a Raspberry PI
From: Robert Heller <heller () deepsoft ! com>
Date: 2017-06-27 11:07:40
Message-ID: 20170627110740.728AC7322DB () sharky3 ! deepsoft ! com
[Download RAW message or body]
At Tue, 27 Jun 2017 09:22:37 +0200 wharms@bfs.de wrote:
>
>
>
> Am 27.06.2017 03:03, schrieb Robert Heller:
> > At Robert Heller <heller@deepsoft.com> wrote:
> >
> > >
> > > At Robert Heller <heller@deepsoft.com> wrote:
> > >
> > > >
> > > > At Tue, 27 Jun 2017 08:55:35 +1000 Peter Hutterer <peter.hutterer@who-t.net> \
> > > > wrote:
> > > > >
> > > > > On Sun, Jun 25, 2017 at 09:20:32AM -0400, Robert Heller wrote:
> > > > > > I have a Raspberry Pi (Model 2 B) running a fairly recent version of \
> > > > > > Raspbian (2017-04-10-raspbian-jessie.zip). I have it start up to the \
> > > > > > console login, since most of the time I just ssh into it from another \
> > > > > > machine (either my CentOS laptop or desktop). I just tied to login into \
> > > > > > its console (using my TV as a monitor) and using the startx command t \
> > > > > > fire up the GUI, but it is failing. I *think* it is having some sort of \
> > > > > > problem with the input device I am using: a combo keyboard / trackball:
> > > > >
> > > > > there are no error messages in the log regarding libinput, it all comes up
> > > > > normally. So whatever the issue is, I don't think that's it. the logind
> > > > > messages looked fine too, so that shouldn't be an issue either.
> > > > >
> > > > > fwiw, you could easily verify it with sudo libinput-debug-events, if that
> > > > > handles the events correctly then the driver will too and you can mostly
> > > > > rule out libinput issues.
> > > >
> > > > Well, libinput-debug-events does not seem to be installed... What package
> > > > would it be in? dpkg-query -l \*libinput\* yields:
> > > >
> > > > Desired=Unknown/Install/Remove/Purge/Hold
> > > > > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> > > > >
> > > > > / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > > > > > / Name Version Architecture Description
> > > > +++-===========================-============-============-===================================================================
> > > > ii libinput-bin 1.5.0-1 armhf input device \
> > > > management and event handling library - udev quirks ii libinput10:armhf \
> > > > 1.5.0-1 armhf input device management and event handling library \
> > > > - shared library ii xserver-xorg-input-libinput 0.20.0-1 armhf \
> > > > X.Org X server -- libinput input driver
> > > > >
> > > > > "it is failing" is a bit generic, what exactly doesn't work?
> > > >
> > > > The XServer does not start -- I type startx, and after a brief startup \
> > > > blather and a brief screen blanking, it lands back at the shell prompt. The \
> > > > log file is all I have. Yes, it appears that XServer sees everything, but for \
> > > > some reason just exits after it has finished probing... No "obvious" (to me) \
> > > > reason (I have seen Xservers die for various reasons, like bad video timing \
> > > > rates on unsupported video chips, or totally missing mice and/or keyboards -- \
> > > > mostly in the "bad old days" where one had to set things up properly in
> > > > /etc/X11/xorg.conf. I believe these days, one does not bother with
> > > > hand-crafter conf files -- the XServer figures itself out "on the fly". (Or
> > > > not as the case might be...)
> > >
> > > OK, another datapoint:
> > >
> > > *I* don't use the "pi" account on my pis -- I create an account "heller" so
> > > make things consistent with my other Linux boxes (an x86_64 home built desktop
> > > and a x86_64 Lenovo Thinkpad laptop).
> > >
> > > When I log into the 'Pi as "pi", startx works. It does not work when I log in
> > > as heller. This is *weird* (at least from this long time Linux user).
> > >
> >
> > OK, problem solved: it was a bad .xsession file. It has been so long since I
> > needed to troubleshoot a .xsession that I had forgotten to check there.
> >
>
> could you elaborate that a bit ?
> When a .xsession causes "could not write pid to lock file in /tmp/.tX1-lock"
> Then it sounds not very helpful, may be that can be changed.
*I* was not having problems with the lock file. My .xsession file was trying
to run a program that was not installed. It was left over from an earlier
version of Raspbian. In the previous version I had installed pieces of Gnome
(specificly gnome-panel), that were not installed when I upgraded the system
(I had backed up /home and restored it after regenerating the micro sd card).
There was also random cruft under ~/.config that was not working properly. I
am now in the process of "re-creating" my desktop environment, while includes
changing the window manager, removing the GUI file manager (which I don't
use), etc.
>
> re,
> wh
>
>
>
> _______________________________________________
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
_______________________________________________
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic