[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Interesting Bug...

From: Ben Spencer
Subject: Re: [STUMP] Interesting Bug...
Date: Thu, 21 Jan 2010 13:07:49 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

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:
> In other words, I'm pretty sure I am...but I could always recompile. ;)

Yep, that's the latest.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]