[02:26] <sgo11> darkxst, hi, are you there? for bug #1288572, I followed your instruction: "export DISPLAY=:0" "xrandr -q" returns "No protocol specified Can't open display :0".
[02:34] <sgo11> I tried "export XAUTHORITY=/home/<user>/.Xauthority", it still gives me the same error output.
[02:35] <sgo11> where .Xauthority is just an empty file.
[02:50] <darkxst> hi sgo11
[02:50] <sgo11> darkxst, hi
[02:51] <darkxst> is the X server still running? or does it get killed when gdm fails?
[02:51] <darkxst> (ps ax | grep X)
[02:52] <sgo11> darkxst, 1396 tty7     Ss+    0:00 /usr/bin/X :0 -background none -verbose -logverbose 7 -core -auth /var/run/gdm/auth-for-gdm-PQ8hDg/database -seat seat0 -nolisten tcp vt7
[02:54] <darkxst> ok maybe because its the gdm X, it has special persmissions
[02:54] <darkxst> so start a new one
[02:54] <darkxst> startx metacity
[02:54] <darkxst> (make sure metacity is installed)
[02:55] <darkxst> then try with export DISPLAY=:1
[03:06] <sgo11> darkxst, just saw your message. installing metacity.
[03:06] <sgo11> darkxst, run it in ssh client? got error: "X: user not authorized to run the X server, aborting."
[03:09] <darkxst> sgo11, you may need to run startx from a VT
[03:10] <darkxst> the rest will work from ssh
[08:02] <PatBateman> morning
[08:03] <PatBateman> i want to ask about ug , so it uses gnome by default and not unity right?
[08:11] <Noskcaj> PatBateman, yep
[13:36] <sgo11> anyone have any ideas how to fix bug #1284856 ?
[19:16] <gnoutchd> Hello all, I've got an (Ubuntu) gnome-shell session here where keyboard and mouse input handling seems to have gotten wedged.
[19:17] <gnoutchd> I've seen this particular problem once or twice before, but I don't know what triggers it.
[19:18] <gnoutchd> In the past, I've been able to clear it up by restarting gnome-shell, but I'm wondering if there's any debugging I should do now before restarting, esp, since this problem rarely occurs.
[19:19] <gnoutchd> The main trouble seems to be that applications aren't getting any mouse or keyboard input events.
[19:20] <gnoutchd> I can confirm this by SSHing in and running xev (with appropriate DISPLAY, etc).  The xev window shows up (so the graphics system seems to be working still), but it reports no mouse or keyboard events.
[19:22] <gnoutchd> Gnome-shell itself still seems to be partially responsive to mouse input, as it responds appropriately to my clicking on the clock or any of the other indicators on the top panel.
[19:22] <gnoutchd> But I am unable to interact with anything else.
[19:23] <gnoutchd> It sorta feels like gnome-shell has taken an X11 input grab and then forgot to let go. (I haven't confirmed that though.)
[19:26] <gnoutchd> I've managed to attach gdb to the affected gnome-shell instance and I was able to get backtraces, but they don't look promising at all (7 threads all waiting in poll(), except for two threads were mozjs is waiting in pthread_cond_wait()).
[19:26] <gnoutchd> And running 'call gjs_dumpstack ()' doesn't produce any output at all.
[19:28] <gnoutchd> BTW this is with the stock gnome-shell shipped in Ubuntu 13.10 (gnome-shell --version says  "3.8.4").
[19:29] <gnoutchd> I can wait for another 1-2 hours or so before I'll have to restart (I will need a working desktop again eventually), but if there's any other debugging info that it would be useful for me to collect, please let know.
[20:01] <gnoutchd> Alright, now I know for certain that this is an input grab problem.  I just ran "xdotool key XF86LogGrabInfo" from SSH, which caused X to log information about input grabs.  As I suspected, gnome-shell has a grab on both the keyboard and the mouse.
[20:08] <gnoutchd> Ah, I think this may be the bug I'm experiencing: https://bugzilla.gnome.org/show_bug.cgi?id=700854
[20:09] <gnoutchd> :heh :)
[20:09] <gnoutchd> Thanks :)
[20:20] <gnoutchd> Yep, I've been able to reproduce my input problem in another user account by middle-clicking on a message tray icon.  And I'm pretty sure that was also the last thing I did before I started experience the problem in my main user account.
[20:21] <gnoutchd> So I consider this bug tracked down.  You may now ignore my previous request for help. :)