Re: [STUMP] Interesting Bug...

[Brit Butler]

Ben,

Sorry I mailed you directly last time.

> Are you aiming for a mirrored display or two heads?

Mirrored, with all windows in all groups taking advantage of the larger resolution. To be clear, I actually shut the laptop lid on the dock as there isn't enough room on the desk for both screens to be open and visible.

xrandr -q before:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192

VGA1 connected (normal left inverted right x axis y axis)

   1680x1050      60.0 +

   1280x1024      75.0     60.0  

   1280x960       60.0  

   1152x864       75.0  

   1024x768       75.1     75.0     70.1     60.0  

   832x624        74.6  

   800x600        72.2     75.0     60.3  

   640x480        72.8     75.0     66.7     60.0  

   720x400        70.1  

LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm

   1280x800       60.0*+   50.0  

   1024x768       85.0     75.0     70.1     60.0  

   832x624        74.6  

   800x600        85.1     72.2     75.0     60.3     56.2  

   640x480        85.0     72.8     75.0     59.9  

   720x400        85.0  

   640x400        85.1  

   640x350        85.1  

HDMI1 disconnected (normal left inverted right x axis y axis)

DP1 disconnected (normal left inverted right x axis y axis)

HDMI2 disconnected (normal left inverted right x axis y axis)

DP2 disconnected (normal left inverted right x axis y axis)

DP3 disconnected (normal left inverted right x axis y axis)

xrandr -q after: 

Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192

VGA1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 297mm

   1680x1050      60.0*+

   1280x1024      75.0     60.0  

   1280x960       60.0  

   1152x864       75.0  

   1024x768       75.1     75.0     70.1     60.0  

   832x624        74.6  

   800x600        72.2     75.0     60.3  

   640x480        72.8     75.0     66.7     60.0  

   720x400        70.1  

LVDS1 connected (normal left inverted right x axis y axis)

   1280x800       60.0 +   50.0  

   1024x768       85.0     75.0     70.1     60.0  

   832x624        74.6  

   800x600        85.1     72.2     75.0     60.3     56.2  

   640x480        85.0     72.8     75.0     59.9  

   720x400        85.0  

   640x400        85.1  

   640x350        85.1  

HDMI1 disconnected (normal left inverted right x axis y axis)

DP1 disconnected (normal left inverted right x axis y axis)

HDMI2 disconnected (normal left inverted right x axis y axis)

DP2 disconnected (normal left inverted right x axis y axis)

DP3 disconnected (normal left inverted right x axis y axis)

I'll try setting *top-level-error-action* to :abort and see if I can't get more details. Thanks again for all your help.

Regards,

Brit

On Thu, Jan 21, 2010 at 8:07 AM, Ben Spencer <address@hidden> wrote:

On Thu, Jan 21, 2010 at 12:19:02AM -0500, Brit Butler wrote:
> I would expect the windows to expand to fill the (added) screen. The laptop
> runs at 1280x800, the VGA monitor at 1680x1050. If the laptop monitor is on
> and I connect and turn on the desktop monitor with lxrandr, the full screen
> real estate is not used. The laptop's 1280x800 resolution is simply mirrored
> on the larger screen. I have not found a simpler way to address this
> (getting *any window* at 1680x1050 resolution) than turning off the laptop
> monitor in lxrandr and iterating through all windows in all groups calling
> (redisplay). That is implemented as fix-layout in my .stumpwmrc and the
> laptop monitor must be *off* in lxrandr for fix-layout to work.

Are you aiming for a mirrored display or two separate heads?

Could you post the output of xrandr -q before and after switching on
the desktop monitor? (just trying to understand what lxrandr is up to).

> *version* returns "0.9.6-39-g545fd7a Compiled On Wed Jan 13 19:12:01". I
> built it from the stumpwm-git package on aur:
> http://aur.archlinux.org/packages.php?ID=12996
> In other words, I'm pretty sure I am...but I could always recompile. ;)

Yep, that's the latest.

> http://redlinernotes.com/docs/stump_backtrace.txt

It looks like you have *top-level-error-action* set to :break (some
instructions for setting up slime recommend this), which is why things
are locking up.  Setting it to :abort should hopefully give you a more
useful backtrace which you can grab with copy-unhandled-error.

(Side note: I'm not really sure what the practical difference between
:abort and :message is.  :abort throws out of the main loop whereas
:message just continues; so I guess the idea is that :abort ensures
you're in a stable state at the cost of a soft reset, whereas :message
leaves everything as it is, risking something somewhere being broken).

As to the bug itself, it looks like it's similar to the issue we had
before in that frame-head can return nil under certain circumstances,
and the caller doesn't expect it.

Ben


_______________________________________________
Stumpwm-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/stumpwm-devel