[solved] i3 and xeyes

EdeWolf · 2019-03-07 18:20:17

Hello,

I am having trouble getting xeyes to display properly with i3. That is, I am missing the transparency. Well, not of the eyes, but of the window that is containing them. Worked fine with KDE, but with I3 the background is solid black and not the wallpaper or the application under it.

I even tried running and configuring compton - never worked with a compositor before - as well as trying to set transset-df in i3.config, but whatever I do, the background remains black.
I've tried:
starting xeyes from .xinitrc as well as i3, same for compton.

exec --no-startup-id compton
exec --no-startup-id /usr/bin/xeyes
exec --no-startup-id /usr/bin/transset-df -n xeyes -m 0 -x 10

From my compton conf:

inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;

opacity-rule = [
    "0:_NET_WM_STATE@[0]:32a = '_NET_WM_STATE_HIDDEN'",
    "10:class_g = 'xeyes' && !_NET_WM_STATE@:32a",
    "92:I3_FLOATING_WINDOW@:c"
];

Any ideal to get my eyes back properly? Or is I3 not for me?

Last edited by EdeWolf (2019-03-10 20:19:48)

Trilby · 2019-03-07 20:09:00

No compositor is needed, xeyes works fine for me and I can assure you my WM is "dumber" than any you've used, there's certainly no compositor.

I suspect the problem is that i3, as a reparenting WM, is creating a container for the xeyes window and that's what you are seeing. I don't use i3, but I've been going through the docs, but I don't see a way to prevent i3 from adding a parent window.

Last edited by Trilby (2019-03-07 20:17:30)

EdeWolf · 2019-03-07 21:29:19

Thanks very much for your reply. You've probably hit the nail. If I reduce the transparency settings for floating windows to lets say 10, xeyes are transparent, but unfortunately so are also the eyes themselves. So even if I would manage to make the xeyes config have precedence over the general floating window setting, it would also fade out the eyes themselves. So its useless. Never been a big fan of compositing anyway, but I've really started to like I3, so this was my last hope

Well, basically, my last hope was maybe some kind of transset-df or similar magic, as indeed they are a dedicated conainter. I had to define them this way to free them from auto tiling:

for_window [class="XEyes"] floating enable
for_window [class="XEyes"] sticky enable
for_window [class="XEyes"] border pixel 0
for_window [class="XEyes"] resize set 125 100
for_window [class="XEyes"] move position 1789 6

However, currently, transset-df only produces pixel distortion for the background.

seth · 2019-03-07 21:36:24

Xeyes does transparency through the xshape extension. If the window is somehow complex embedded, this will probably fail (xeyes being shaped, but the bed isn't) - this has nothing to do w/ compositing and xeyes doesn't have ARGB support.
Does it also happen when you allow them to be tiled?

EdeWolf · 2019-03-08 18:22:08

Thanks very much. compton and transset-df have been deinstalled again. A good start. The behaviour of xeyes, when tiled, varies. In fact, it looks a bit buggy. Wether it is X or i3, I do not know.

Sometimes after loading xeyes, the wallpaper is visible, albeit heavily distorted, but for most of the time the background is black. And that black, to my suprise, does not seem to be related to the colour of the root window. I can "xsetroot -solid green" and the xeyes background remains black.

Now, my first workspace features two urxvt terminals with pseudo transparency. When I open xeyes there, the background is transparent most of the time - albeit then usually heavily distored. However, if I reload the i3 configuration ($mod + shift + r, default config, without having changed anything), the background of xeyes changes. Sometimes it is the plain wallpaper, or 100% transparency, sometimes the faded wallpaper as configured for urxvt, then distored again. If I reload enough times, the background is as one would expect.

On the other workspaces, where f.e firefox or krusader are run or that are empty, if I load xeyes there, the background is black. Upon reload, it remains black, but may gather slight distortion. Switching then back to workspace 1 after couple of reloads, the xeyes background, that was ok before, is now black/white distorted, but reloading the i3 config a couple of time makes it transparent again. With or without distortion.

It does not seem to make a great deal of diference wether xeyes has been started from dmenu or from a terminal.

Not sure, what to think about this. I do remember, when having run transset-df on the fixed container xeyes, the background was distored as well, with a transparent distortion the upper half and a black one the lower half of the xeyes window.

Edit: When removing the .Xdefaults, that only hosts the urxvt settings anyway, the issue remains, just that now I have the choise of black with small vertical grey lines as distortion or upper half white and lower half black with little distortion.
On an emtpy workspace xeyes seem to come up fine (solid black with no distorion). However, after a couple of reloads or workspace switching the get the grey line distortion as well.
Hints slightly more to an i3 issue than a X.org one. But I am on thin ice here.

Last edited by EdeWolf (2019-03-08 18:31:17)

seth · 2019-03-08 21:34:59

Briefly substitute i3 w/ openbox - if it works, it's safe to say that it's the i3 container.
What's the output of "xprop" and "xwininfo" when clicking into the xeyes area that ought to be transparent?
https://www.archlinux.org/packages/extr … rg-oclock/ will bwt. show the same behavior?

EdeWolf · 2019-03-09 19:38:33

I tested with fvmw and KDE, hoping that this is fine for testing as well. Here xeyes work as expected. The xprop output of the background window is identical in all cases. Be it black, transparent or distored.

_NET_WM_STATE(ATOM) = 
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
WM_CLIENT_LEADER(WINDOW): window id # 0x1a0000a
WM_LOCALE_NAME(STRING) = "de_DE.UTF8"
WM_CLASS(STRING) = "xeyes", "XEyes"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Normal State.
		bitmap id # to use for icon: 0x1a00001
		bitmap id # of mask for icon: 0x1a00003
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 150 by 100
		window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "kaperfahrt"
WM_COMMAND(STRING) = { "xeyes" }
WM_ICON_NAME(STRING) = "xeyes"
WM_NAME(STRING) = "xeyes"

Edit: Here is a xprop output, when the eyes are forced floating and be always on top, with the background being black, but remaining black and undistorted even across multiple config reloads.

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 4294967295
_NET_WM_STATE(ATOM) = _NET_WM_STATE_STICKY
I3_FLOATING_WINDOW(CARDINAL) = 1
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
WM_CLIENT_LEADER(WINDOW): window id # 0xe0000a
WM_LOCALE_NAME(STRING) = "de_DE.UTF8"
WM_CLASS(STRING) = "xeyes", "XEyes"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Normal State.
		bitmap id # to use for icon: 0xe00001
		bitmap id # of mask for icon: 0xe00003
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 150 by 100
		window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "kaperfahrt"
WM_COMMAND(STRING) = { "/usr/bin/xeyes" }
WM_ICON_NAME(STRING) = "xeyes"
WM_NAME(STRING) = "xeyes"

Not sure wether there is any usable information in here, but thanks again for your time and effort.

Last edited by EdeWolf (2019-03-09 19:46:32)

EdeWolf · 2019-03-09 19:58:07

And here the xwinoutput. First floating/on top, second regular started from shell. Not much difference, though:

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xe0000a "xeyes"

  Absolute upper-left X:  1789
  Absolute upper-left Y:  6
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 123
  Height: 98
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1789+6  -6+6  -6-974  +1789-974
  -geometry 123x98-6+6

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x1a0000a "xeyes"

  Absolute upper-left X:  1284
  Absolute upper-left Y:  8
  Relative upper-left X:  2
  Relative upper-left Y:  2
  Width: 626
  Height: 1043
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1284+8  -8+8  -8-27  +1284-27
  -geometry 626x1043-6+6

xclock, when started from dmenu or shell, has always a white, undistorted background. As with fvwm for example. No matter how often I reload the config.
Have not yet tried to force it to a certain size and be floating always on top. Will follow up with that.

Edit: xclock, when started forced floating on top, stays white as when called by dmenu or a terminal. So distortion only seem to occur a) with xeyes and b) when started from dmenu/shell - can temporarily healed with config reloads - or when transset-df has been applied to the floating xeyes.
Otherwise, the clock has a white background, the eyes a black one. Latter one being quite unfortunate.

Last edited by EdeWolf (2019-03-09 20:10:33)

seth · 2019-03-09 20:38:07

"oclock" is not "xclock" - the xeyes window does not seem to be shaped. You'd get the window below in that case (what should happen on KDE/fvwm) - unless you clicked into the visible eye.
Does it make a difference whether you run "xeyes -shape" or "xeyes +shape"? Output of "xwininfo -shape"?

EdeWolf · 2019-03-10 00:26:30

Mea clupa! I did not read carefully enough. Thanks for the heads up. Yes, oclock behaves identical to xeyes. When started on a blank workspace from dmenu it starts up with a black background, when started on a workspace with an urxvt with pseudo tranparency it has a distorted transparent background. Upon reloading the i3 config enough times, the background will be clear transparent or faded transparent while the black background will distort.

Running xeyes -shape behaves identical to no arguments, +shape gives a white background as with xclock, that remains clean. As does oclock -noshape.

For both, oclock as well as xeyes, I said when started floating and therefore with a black background, the background will be stable upon config reloads. That is still true, but as soon as I resize those windows, distortion will occur. I believe I did not mention this.

Edit:

xwininfo -shape on xeyes -shape:

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x140000a "xeyes"

  Absolute upper-left X:  644
  Absolute upper-left Y:  8
  Relative upper-left X:  2
  Relative upper-left Y:  2
  Width: 630
  Height: 1043
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +644+8  -644+8  -644-27  +644-27
  -geometry 630x1043+642+6

  Window shape extents:  629x1043+1+0
  No border shape defined

xwininfo -shape on xeyes +shape:

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x140000a "xeyes"

  Absolute upper-left X:  644
  Absolute upper-left Y:  8
  Relative upper-left X:  2
  Relative upper-left Y:  2
  Width: 630
  Height: 1043
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +644+8  -644+8  -644-27  +644-27
  -geometry 630x1043+642+6

  No window shape defined
  No border shape defined

Last edited by EdeWolf (2019-03-10 00:29:40)

EdeWolf · 2019-03-10 00:42:34

And finally the output of xwininfo -shape, when xeyes has been started floating:

xeyes +shape:

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xc0000a "xeyes"

  Absolute upper-left X:  1789
  Absolute upper-left Y:  6
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 148
  Height: 98
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1789+6  --19+6  --19-974  +1789-974
  -geometry 148x98--19+6

  No window shape defined
  No border shape defined

xeyes -shape:

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0xc0000a "xeyes"

  Absolute upper-left X:  1789
  Absolute upper-left Y:  6
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 148
  Height: 98
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 1
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1789+6  --19+6  --19-974  +1789-974
  -geometry 148x98--19+6

  Window shape extents:  147x97+1+0
  No border shape defined

seth · 2019-03-10 08:50:18

The window has the shape set, but it seems i3wm only very recently got support for the shape extension:
https://github.com/i3/i3/pull/3514

You might try https://aur.archlinux.org/packages/i3-git/

EdeWolf · 2019-03-10 20:19:23

Thanks very much again. I will try the git version. Even in case it should not work, we now know where the limiting factor is. But it seems to be work in progress, that is good:

https://:github.com/i3/i3/issues/1966

Arch Linux

#1 2019-03-07 18:20:17

[solved] i3 and xeyes

#2 2019-03-07 20:09:00

Re: [solved] i3 and xeyes

#3 2019-03-07 21:29:19

Re: [solved] i3 and xeyes

#4 2019-03-07 21:36:24

Re: [solved] i3 and xeyes

#5 2019-03-08 18:22:08

Re: [solved] i3 and xeyes

#6 2019-03-08 21:34:59

Re: [solved] i3 and xeyes

#7 2019-03-09 19:38:33

Re: [solved] i3 and xeyes

#8 2019-03-09 19:58:07

Re: [solved] i3 and xeyes

#9 2019-03-09 20:38:07

Re: [solved] i3 and xeyes

#10 2019-03-10 00:26:30

Re: [solved] i3 and xeyes

#11 2019-03-10 00:42:34

Re: [solved] i3 and xeyes

#12 2019-03-10 08:50:18

Re: [solved] i3 and xeyes

#13 2019-03-10 20:19:23

Re: [solved] i3 and xeyes

Board footer