| 1 |
On Sat, Jul 29, 2017 at 11:17 AM, Mart Raudsepp <leio@g.o> wrote: |
| 2 |
> Ühel kenal päeval, L, 29.07.2017 kell 13:20, kirjutas tuxic@××××××.de: |
| 3 |
>> The task is already accomplished :) with a mixture of WM-based |
| 4 |
>> hotkey definitions and a delayed commandline utility (main,scrot, |
| 5 |
>> imagemagick). |
| 6 |
>> Addtionally I dont think that my X11 uses framebuffer (not shure |
| 7 |
>> about that, though)... |
| 8 |
> |
| 9 |
> Those tools work by using an inherent X11 security hole by reading out |
| 10 |
> the root window, it's not relevant to framebuffer in the kernel sense. |
| 11 |
> |
| 12 |
> Note that you can't use a global shortcut key in X11 while a typical |
| 13 |
> right click context menu is open, because these take a X11 grab and |
| 14 |
> even screen lock can't activate.. Then only the delay approach will |
| 15 |
> work (if desired then together with a shortcut if the shortcut key is |
| 16 |
> hit before opening the context menu). Fortunately in this case you only |
| 17 |
> wanted a dropdown in firefox, which isn't implemented like that. |
| 18 |
> This popup menu problem is solved with Wayland (most importantly the |
| 19 |
> not screenlocking aspect of it), but so is the root window security |
| 20 |
> hole, so the compositor/WM needs to take the screenshot and tools like |
| 21 |
> import/scrot won't work. |
| 22 |
> |
| 23 |
|
| 24 |
I'm not really sure it is fair to call that a security problem. It's |
| 25 |
intentional, and that is because there are plenty of things that need |
| 26 |
access to the whole desktop at once. E.g. automating anything that |
| 27 |
doesn't expose a development API or have an accessibility API can |
| 28 |
pretty much only be done by scraping the contents of the screen - |
| 29 |
these programs simply don't work in Wayland? That seems like a |
| 30 |
misfeature. |
| 31 |
|
| 32 |
R0b0t1. |
Archives