Does it work with awesome 3.5?

[vonpupp]

Greetings @k3rni,
I'm trying foggy with awesome 3.5.

%awesome --version
awesome v3.5.6 (For Those About To Rock)
 • Build: May  5 2015 05:45:29 for x86_64 by gcc version 5.1.0 (builduser@)
 • Compiled against Lua 5.3.0 (running with Lua 5.3)
 • D-Bus support: ✔

But when I mod+p as it is on the readme I get the following error:

~/.config/awesome/foggy/menu.lua:19: attempt to index a nil value (local 'xs')

Does foggy work with awesome 3.5?

Thank you very much.
Regards.

[k3rni]

Currently using it with the exact same version you're posting; although it's compiled with Lua 5.1 rather than 5.3. It's possible that Lua changed the semantics of global variables and/or modules (again), this might have caused your problem. I'll take a look.

[vonpupp]

Thank you for your answer.

I confirm I'm using Lua 5.3 on Arch Linux. I haven't seen your script on
the Awesome wiki, I would suggest to include it there, it seems to be very
helpful. I can do that for you, unfortunately I don't know how to fix it
and to properly debug Lua.

Regards.

On Fri, Nov 20, 2015 at 7:58 AM, Krzysztof Zych notifications@github.com
wrote:

Currently using it with the exact same version you're posting; although
it's compiled with Lua 5.1 rather than 5.3. It's possible that Lua changed
the semantics of global variables and/or modules (again), this might have
caused your problem. I'll take a look.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Albert.

[k3rni]

Besides Lua, this can be a problem with parsing Xinerama info. Can you provide the output of running

xdpyinfo -ext XINERAMA

on the machine where it causes problems?

[vonpupp]

Hello @k3rni,
I didn't had that package installed so I installed. After installing I am still getting the same error. Do I need any other dependency?

Since the log is quite verbose I put it on this gist

Regards.

[k3rni]

Please try the updated version. I discovered that when EDID isn't reporting the model name, two places in the code can break. This is often the case with laptop displays, but didn't occur on my machines.

To verify whether your display reports its model name, install read-edid and run get-edid | parse-edid.

[k3rni]

Note: read-edid isn't necessary for running foggy, just for testing.

[vonpupp]

Thanks for your feedback @k3rni,

The output of my regular user didn't return much information, I had to sudo it. Herewith the output of the command you gave me (with sudo). Unfortunately I am still having the same error. Do I have to install something explicitly for Xinerama or is it embedded within Xorg?

Regards.

[k3rni]

Yes, it should be ran under sudo, I forgot to mention that. Your output is somewhat strange, but shouldn't be a problem. As for xinerama, it's built in to Xorg, and enabled on your machine, which I know from the xdpyinfo output you provided earlier. Let's try more things:

1. the output of xrandr --query --properties
2. the full traceback that awesome prints. It's wherever your X session stores its standard output, typically in one of $HOME/.xsession-errors, $HOME/.cache/gdm/session.log, or systemd's session logs. However, you provided a line of traceback right at the start, so you probably already know how to access it.

Find which file is your session log, run tail -f on it, and watch its output when you press mod+p. Paste all lines that appear when pressing the combination.

[vonpupp]

Hello @k3rni,
Herewith the answers:

1. The output of xrandr --query --properties is here
2. And the output of the log is this:

%cat ~/.cache/awesome/stderr 
Trying location provider `geoclue2'...
unagi: no process found
W: awesome: luaA_dofunction:78: error while running function
stack traceback:
    /home/av/.config/awesome/foggy/menu.lua:19: in function 'foggy.menu.get_output'
    /home/av/.config/awesome/foggy/menu.lua:188: in upvalue 'build_menu'
    /home/av/.config/awesome/foggy/menu.lua:210: in function 'foggy.menu.menu'
    (...tail calls...)
    /usr/share/awesome/lib/awful/key.lua:42: in function </usr/share/awesome/lib/awful/key.lua:42>
error: /home/av/.config/awesome/foggy/menu.lua:19: attempt to index a nil value (local 'xs')

Note that I don't use GDM, I use Slim so I had to modify my .xinitrc to dump stderr to a file, I guess this is what you need.

Thank you very much!

[k3rni]

Thanks for the traceback, it's most useful. It seems that the error was unrelated to EDID parsing. What's probably happening is that foggy can't properly guess what screen your mouse cursor is on. I need more things:

1. the exact keybinding line you used, if different from the one in README
2. modify menu.lua to add these statements into function menu.menu(current_screen), right at the top, so it looks like this:

function menu.menu(current_screen)
  io.stderr:write("current screen: " .. (current_screen or "nil") .. "\n")
  io.stderr:write("mouse screen: " .. (mouse.screen or "nil") .. "\n")
  io.stderr:write("mouse coords: " .. mouse.coords().x .. "," .. mouse.coords().y .. "\n")
  -- rest of function untouched

and please report the additional output it now prints before the traceback.

As an aside, I regularly use awesome with foggy on two and three-screen setups. Your case should be routine, but still evades an explanation :)

[vonpupp]

Hello @k3rni,
Herewith the answers:

1. It is the same as on the readme except for the keydoc documentation. I use a monkey patched version to have F1 help on my keys in case I forget, so the keybinding is: awful.key({ modkey }, "p", foggy.menu, "Xrandr foggy cycle"),
2. I did it as you said, and here is the output. I confirm that the mouse coords do change correctly.

current screen: nil
mouse screen: 1.0
mouse coords: 1001.0,395.0
W: awesome: luaA_dofunction:78: error while running function
stack traceback:
    /home/av/.config/awesome/foggy/menu.lua:19: in function 'foggy.menu.get_output'
    /home/av/.config/awesome/foggy/menu.lua:188: in upvalue 'build_menu'
    /home/av/.config/awesome/foggy/menu.lua:216: in function 'foggy.menu.menu'
    (...tail calls...)
    /usr/share/awesome/lib/awful/key.lua:42: in function </usr/share/awesome/lib/awful/key.lua:42>
error: /home/av/.config/awesome/foggy/menu.lua:19: attempt to index a nil value (local 'xs')

As always, thank you very much!

[k3rni]

No problems with the keybinding; what matters here is that you don't pass any additional arguments to foggy.menu() that may throw it off. However, it's interesting that you get 1.0 (a floating point number) instead of just an integer, as I do in my tests. This is probably related to Lua 5.3's changes in float and integer number handling.

In 5.3:

print(tostring(1.0 - 1))
0.0

While in 5.1:

print(tostring(1.0 - 1))
0

Replacing this code with string.format() should help, and I did just that in 70c2a2a. Please try the latest version.

[vonpupp]

Thank you @k3rni,

I confirm it now works, and I'm able to see the menu, amazing! However, I stumbled with another bug. Steps to reproduce:

1. Use mod-p, go to mode (my current mode is 1366x768@60.
2. Change the mode to 1024x768@60. This works fine. Now repeat it again to go back to the prior mode
3. Use mod-p again and go to mode, and select 1024x768@60 and an error pops up:

Herewith the full trace:

W: awesome: luaA_dofunction:78: error while running function
stack traceback:
    [C]: in function 'string.format'
    /home/av/.config/awesome/foggy/xrandr.lua:160: in field 'set_mode'
    /home/av/.config/awesome/foggy/menu.lua:80: in local 'cmd'
    /usr/share/awesome/lib/awful/menu.lua:260: in function 'awful.menu.exec'
    /usr/share/awesome/lib/awful/menu.lua:403: in upvalue 'press'
    /usr/share/awesome/lib/awful/button.lua:42: in function </usr/share/awesome/lib/awful/button.lua:42>
    [C]: in method 'emit_signal'
    /usr/share/awesome/lib/wibox/widget/base.lua:59: in function 'wibox.widget.base.handle_button'
    (...tail calls...)
    /usr/share/awesome/lib/gears/object.lua:68: in function 'gears.object.emit_signal'
    /usr/share/awesome/lib/wibox/drawable.lua:279: in function </usr/share/awesome/lib/wibox/drawable.lua:273>
error: /home/av/.config/awesome/foggy/xrandr.lua:160: bad argument #5 to 'format' (number has no integer representation)

Note that if I go to mode - auto it works fine. Perhaps it is a similar issue with argument casting.

[k3rni]

Glad to hear it works. As for the second problem, I'll post this as a new issue and close this one.

[vonpupp]

Great, thank you very much for your support!