3hhh

Hm... I just realized that I probably shouldn't have taken the xprops as I did above: Qubes OS essentially runs two X servers in different VMs and the xprops above...

> > I haven't had the time to understand the layering code in detail, but my guess is there's some problem there. > > I take no offence from that!...

No, that's still not it. I had [a look at the incoming X11 events](https://github.com/qtile/qtile/blob/16b870596e4087cfdaa21da63e1637ec2e5f6540/libqtile/backend/x11/core.py#L302) and noticed that qtile never receives any map request. Ironically it receives an unmap event, but...

Argh. I'm beginning to understand... So probably the context menu has an override-redirect flag, Xorg therefore doesn't forward it to qtile and qtile cannot position it on top of all...

Hm, my initial testing also reveals some issues with transient windows, which are rendered behind neighboring windows. To reproduce: 1. On an empty workspace in MonadTall layout with `new_client_position =...

Uh. And I had considered this one to be tough nut to crack... Thanks a lot for the hint, it's much appreciated!

I tried to patch the aforementioned two files, but unfortunately attaching block devices still fails at `/dev/xvde`, i.e. `xvde` to `xvdh` are never created. So the current limit appears to...

Qubes OS treats `/dev/xvda` to `xvdh` in a special way: Apparently those devices are hidden from tools such as `qvm-block ls`, which caused issues with my test code. Not sure...

P.S.: Writing the 1G file in dom0 with dd takes roughly those 20s, i.e. that would be the max speed for my system it appears.

Here's a full copy of my test run today: ``` > time dd if=/dev/urandom of=~/test bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied,...