Re: [DNG] Mouse won't release in Devuan beta 2 with Qemu

2016-12-29 Thread Steve Litt 
On Thu, 29 Dec 2016 18:27:00 +
KatolaZ  wrote:

> On Thu, Dec 29, 2016 at 01:18:34PM -0500, Steve Litt wrote:
> > Hi all,
> > 
> > Fsmithred and I have put a heckofa lot of time into this, and
> > frankly need help from everyone who can reproduce this problem
> > (Fsmithred can't).
> > 
> > The problem is this:  When you run either Refracta or Devuan Jessie
> > Beta 2 in a Qemu guest (on a Void Linux host), run the GUI, and
> > click the mouse in the guest so that the mouse is captured by the
> > guest:
> > 
> > 1) You cannot get the mouse pointer to go outside the guest window,
> >whether or not you press the ungrab hotkey.
> > 
> > 2) Pressing the hotkey that would ordinarily get you to another
> >workspace on the host doesn't work.
> > 
> > 3) As a result, your only way of using other programs on the host
> > is to: a) Log out of the gui so you're confronted with the login
> > window, b) Press the ungrab key combo, and c) move the mouse where
> > you want it to go.
> >   
> 
> 
> Hi,
> 
> it looks like whatever-desktop-envinroment you are using on the *host*
> system is grabbing the default hot-key sequence to exit from qemu
> (which is Ctrl+Alt). You may try to start qemu with either "-alt-grab"
> or "-ctrl-grab", which would change the ungrab sequence to
> "Ctrl-Shift-Alt" or "Right-Ctrl", respectively. Or instead you can try
> to execute qemu from an X session without a DM (i.e., started with
> "xinit /usr/bin/xterm -- :1").

Thanks KatolaZ,
I tried -ctrl-grab, -alt-grab, and neither ON THE DEVUAN QEMU GUEST,
and the results were the same.

The host uses Openbox. Next time I shut everything down and restart X,
I'll try it with Xfce and fvwm ON THE HOST and see if that changes
things.

Thanks,

SteveT

Steve Litt 
December 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] upower and the version numbering

2016-12-29 Thread Alexis PM 
You're right, the problem is a cross between repositories that use different 
strategies for the renaming of their nosystemd-versions. 

Thank you very much!

  De: Petr Gajdůšek 
 Para: dng@lists.dyne.org 
CC: Alexis PM 
 Enviado: Miércoles 28 de diciembre de 2016 0:40
 Asunto: Re: [DNG] upower and the version numbering
   
Hi Alexis,

You cannot have xfce4-power-manager from angband.pl installed
together with Devuan's upower. Also angband.pl xfce4-power-manager
dependencies are not strict enough to prevent upower from Debian Jessie
(0.99.1-3.2) being considered as candidate.

I guess, if you do not pin, this situation is too complicated for
apt-get/aptitude resolver.

But there is no problem with Devuan (except maybe that it adds epoch to
upower which IMHO could be avoided).

It seems you have problem because you are mixing various sources and do
not have appropriate apt pinning setup.

petr:~$ apt-cache policy xfce4-power-manager upower
xfce4-power-manager:
  Installed: 1.4.1-1
  Candidate: 1.4.1-1
  Version table:
    1.6.0-1 0
        -1 http://ftp.cz.debian.org/debian/ experimental/main amd64
Packages 1.4.4-4 0
        400 http://packages.devuan.org/merged/ ascii/main amd64 Packages
        300 http://packages.devuan.org/merged/ ceres/main amd64 Packages
        -1 http://ftp.cz.debian.org/debian/ testing/main amd64 Packages
        -1 http://ftp.cz.debian.org/debian/ sid/main amd64 Packages
    1.4.1-2.0nosystemd1 0
        500 http://angband.pl/debian/ nosystemd/main amd64 Packages
 *** 1.4.1-1 0
        999 http://packages.devuan.org/merged/ jessie/main amd64
Packages -1 http://ftp.cz.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
    1.0.11-2+b1 0
        100 http://ftp.cz.debian.org/debian/ wheezy/main amd64 Packages
upower:
  Installed: 1:0.9.23-2+devuan1.2
  Candidate: 1:0.9.23-2+devuan1.2
  Version table:
    1:0.9.23-2.0nosystemd3 0
        350 http://angband.pl/debian/ nosystemd-stretch/main amd64
Packages *** 1:0.9.23-2+devuan1.2 0
        999 http://packages.devuan.org/merged/ jessie/main amd64
Packages 400 http://packages.devuan.org/merged/ ascii/main amd64
Packages 300 http://packages.devuan.org/merged/ ceres/main amd64
Packages 100 /var/lib/dpkg/status
    0.99.4-4 0
        -1 http://ftp.cz.debian.org/debian/ testing/main amd64 Packages
        -1 http://ftp.cz.debian.org/debian/ sid/main amd64 Packages
    0.99.1-really-0.9.23-2.0nosystemd1 0
        500 http://angband.pl/debian/ nosystemd/main amd64 Packages
    0.99.1-3.2 0
        -1 http://ftp.cz.debian.org/debian/ jessie/main amd64 Packages
    0.9.17-1 0
        100 http://ftp.cz.debian.org/debian/ wheezy/main amd64 Packages

> In Devuan Jessie, xfce4-power-manager is not (easily) installable
> because depends of upower (< 0.99.2) but Devuan's upower version
> number is 1:0.9.23-2+devuan1.2 while Debian Jessie 's upower version
> number is 0.99.1-3.2.

xfce4-power-manager package is not forked in Devuan. It depends on
upower (>= 0.99). I think you confused it with angband.pl
xfce4-power-manager (1.4.1-2.0nosystemd1) ?

Devuan/Debian xfce4-power-manager is satisfied by upower
1:0.9.23-2+devuan1.2 because of the epoch, and it is also the only
upower package in Devuan repositories.

IMHO xfce4-power-manager should be forked and its dependency on upower
lowered instead of adding epoch to upower. Because either upower >=
0.99 is not needed or we are already breaking xfce4-power-manager
functionality.

Petr


   ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Mouse won't release in Devuan beta 2 with Qemu

2016-12-29 Thread golinux 

On 2016-12-29 12:27, KatolaZ wrote:

On Thu, Dec 29, 2016 at 01:18:34PM -0500, Steve Litt wrote:

Hi all,

Fsmithred and I have put a heckofa lot of time into this, and frankly
need help from everyone who can reproduce this problem (Fsmithred
can't).

The problem is this:  When you run either Refracta or Devuan Jessie
Beta 2 in a Qemu guest (on a Void Linux host), run the GUI, and click
the mouse in the guest so that the mouse is captured by the guest:

1) You cannot get the mouse pointer to go outside the guest window,
   whether or not you press the ungrab hotkey.

2) Pressing the hotkey that would ordinarily get you to another
   workspace on the host doesn't work.

3) As a result, your only way of using other programs on the host is 
to:

a) Log out of the gui so you're confronted with the login window,
b) Press the ungrab key combo, and c) move the mouse where you 
want

it to go.




Hi,

it looks like whatever-desktop-envinroment you are using on the *host*
system is grabbing the default hot-key sequence to exit from qemu
(which is Ctrl+Alt). You may try to start qemu with either "-alt-grab"
or "-ctrl-grab", which would change the ungrab sequence to
"Ctrl-Shift-Alt" or "Right-Ctrl", respectively. Or instead you can try
to execute qemu from an X session without a DM (i.e., started with
"xinit /usr/bin/xterm -- :1").

My2Cents

KatolaZ


-

Testing just now for Steve and am able to move the cursor freely from 
guest to host and back again.  Release key was required earlier this 
month.  Go figure . . .


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Mouse won't release in Devuan beta 2 with Qemu

2016-12-29 Thread KatolaZ 
On Thu, Dec 29, 2016 at 01:18:34PM -0500, Steve Litt wrote:
> Hi all,
> 
> Fsmithred and I have put a heckofa lot of time into this, and frankly
> need help from everyone who can reproduce this problem (Fsmithred
> can't).
> 
> The problem is this:  When you run either Refracta or Devuan Jessie
> Beta 2 in a Qemu guest (on a Void Linux host), run the GUI, and click
> the mouse in the guest so that the mouse is captured by the guest:
> 
> 1) You cannot get the mouse pointer to go outside the guest window,
>whether or not you press the ungrab hotkey.
> 
> 2) Pressing the hotkey that would ordinarily get you to another
>workspace on the host doesn't work.
> 
> 3) As a result, your only way of using other programs on the host is to:
> a) Log out of the gui so you're confronted with the login window,
> b) Press the ungrab key combo, and c) move the mouse where you want
> it to go.
> 


Hi,

it looks like whatever-desktop-envinroment you are using on the *host*
system is grabbing the default hot-key sequence to exit from qemu
(which is Ctrl+Alt). You may try to start qemu with either "-alt-grab"
or "-ctrl-grab", which would change the ungrab sequence to
"Ctrl-Shift-Alt" or "Right-Ctrl", respectively. Or instead you can try
to execute qemu from an X session without a DM (i.e., started with
"xinit /usr/bin/xterm -- :1").

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Mouse won't release in Devuan beta 2 with Qemu

2016-12-29 Thread Steve Litt 
Hi all,

Fsmithred and I have put a heckofa lot of time into this, and frankly
need help from everyone who can reproduce this problem (Fsmithred
can't).

The problem is this:  When you run either Refracta or Devuan Jessie
Beta 2 in a Qemu guest (on a Void Linux host), run the GUI, and click
the mouse in the guest so that the mouse is captured by the guest:

1) You cannot get the mouse pointer to go outside the guest window,
   whether or not you press the ungrab hotkey.

2) Pressing the hotkey that would ordinarily get you to another
   workspace on the host doesn't work.

3) As a result, your only way of using other programs on the host is to:
a) Log out of the gui so you're confronted with the login window,
b) Press the ungrab key combo, and c) move the mouse where you want
it to go.


WHAT THE SYMPTOM LOOKS LIKE
---
Specifically, on Refracta and Devuan, when your guest window is not
maximized, you move your mouse pointer to an edge of the guest window
and beyond, and the pointer sticks at the edge, while the "Qemu: Press
Right Ctrl to exit grab" titlebar changes to just "Qemu". The mouse
pointer is not visible outside the guest window, nor do host hotkeys
work.

As a reminder, the way it should work (at least according to a Void
guest and a Lubuntu 16.04 guest) is you move your mouse pointer to an
edge of the guest window and beyond, and the pointer sticks at the
edge, while the "Qemu: Press Right Ctrl to exit grab" titlebar changes
to just "Qemu", BUT A SECOND MOUSE POINTER APPEARS OUTSIDE THE GUEST
WINDOW, AND HOST HOTKEYS BECOME ENABLED. Furthermore, on Lubuntu and
Void guests, pressing the ungrab hotkey enables host hotkeys to be
used, but on Refracta and Devuan it doesn't.

For the rest of this email, I'll refer to the way Void and Lubuntu
hosts work as "as expected".


DISTINCTIONS

Fsmithred and I have discovered many distinctions that we hope can
narrow the root cause scope on this situation:

* This happens only when the gui is running. When Devuan is running in
  CLI mode (because I disabled the lightdm daemon and didn't startx or
  quit a gui started by startx), it works as expected.

* This happens only with Devuan, Refracta and Sublinux. It doesn't
  happen with Lubuntu or Void. With Sublinux, you can play tricks with
  the mouse and ungrab key combo to escape grab.

* This happens with a Devuan qemu guest I had from May 12, 2016. I
  don't know if it was beta or alpha, and neither uname -a nor
  cat /etc/issue helped me answer that question.

* This happens on Xfce, LXDE, and Openbox with Refracta (and I'd assume
  Devuan Beta).

* This happens in Refracta's live CD mode. It does *not* happen during
  Devuan's install process.

* In Refracta, disabling all vbox* daemons did not eliminate the
  symptom.


SIGNIFICANCE

I have no data as to whether this behavior occurs in a Virtualbox guest
because I've not been able to get Virtualbox working on my Void host.
Long before switching to Void, I stopped using Virtualbox because I
found it intermittent and crashy. There are probably others who aren't
good candidates for Virtualbox, so if it turns out this behavior
doesn't occur on a Virtualbox guest, that's not a "solution."

The preceding paragraph notwithstanding, trying to reproduce this
problem in Virtualbox would be a great *diagnostic test*. But a lousy
solution. I'd do it in Virtualbox myself except so far I haven't been
able to get Virtualbox running on my Void host.

In certain use cases, this situation can be a showstopper. A great deal
of distro experimentation is done in Qemu guests, and the requirement
of having to log out of GUI every time you want to switch out of a
guest is a productivity destroyer.

The point could be made that one could (presumably) get around this
problem by using ssh -Y to run guest programs from a host ssh session.
Such an ssh solution would probably work, but it requires much more
sophisticated networking in the guest, GUI programs would run noticibly
slower, and the SSH "solution" is a big departure from the typical
"quick and dirty experimental setup."

The bottom line is this: This Qemu/(Refracta|Devuan) problem is a
significant impediment to using Refracta and Devuan, and unless it
turns out I'm the only person on the planet having this problem, the
goal should be to fix it, not to suggest workarounds.


WHAT I'M ASKING FOR
---
I've gone as far as I can in diagnosting this problem, given the
demands of everything else on my todo list. Fsmithred has also put in
significant time, but cannot reproduce the symptom. We need help, and
the first piece of help we need is for people to try to reproduce this
behavior. The following shellscript should do the trick:

 qemu-system-x86_64 -m 4096 -hda devuan.img -boot d -ctrl-grab \
 -cdrom   devuan_jessie_1.0.0-beta2_amd64_CD.iso \
 -vga std  -enable-kvm \
 -netdev user,id=mynet0  -device e1000,netdev=mynet0

In the preceding,