[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)

2008-10-24 Thread dynamotwain
You have to close and restart AWN after changing the monitor. These are things AWN had wrong before because AWN currently stores all of its settings in a AwnSettings class (which gets updated when the GConf values change) but it doesn't propagate those changes to the rest of AWN. AwnPanel, AwnHotsp

[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)

2008-10-19 Thread dynamotwain
Ah, good to hear. I didn't know about a rewrite, and normally one expects to find the latest bleeding edge code in trunk. I haven't been following or using AWN until just recently when I got Openbox to work properly with shaped windows like AWN uses. I just took a look at the 'trunk-rewrite-and-ra

[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)

2008-10-19 Thread dynamotwain
The bundle contains a series of commits that more or less can be applied individually. The later three directly deal with positioning and don't depend too much on the prior commits. The changes sorted by my opinion of 'invasiveness', from most to least: 1. Updated docs files: Some types might have

[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)

2008-10-19 Thread dynamotwain
The attached bzr bundle/patch is against trunk and fixes the following: * Building against GTK with GTK_DISABLE_DEPRECATED defined * GObject-ify AwnSettings so that AwnMonitor functionality can be merged in * Merge AwnMonitor and duplicated AwnSettings entries so monitor geometry is only stored in

[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)

2008-10-19 Thread dynamotwain
If it used to work for you in this exact setup, then you were experiencing broken behavior. What you are trying to do is put a 'strut', a window docked on a monitor edge that takes space away from maximized windows, and place it on an 'internal edge', an edge shared by two monitors--in this case, t

[Bug 114953] Re: acpi_fakekey sends events to wrong evdev device

2007-08-30 Thread dynamotwain
Here's the keyboard portion of my Xorg.conf: Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "AutoRepeat" "250 50" Option "XkbModel" "pc104" Option "XkbLayout" "us" Option "XkbOptions" "compose:menu,lv3:ralt_switch

[Bug 114953] Re: acpi_fakekey sends events to wrong evdev device

2007-05-15 Thread dynamotwain
This patch makes acpi_fakekey only consider evdev devices with keys commonly found on all keyboards by requiring the evdev keycode to be less than KEY_MACRO. KEY_MACRO through BTN_MISC are just F13 - F24 and multimedia, quick launch, and power management keys. Ignoring them allows the real keyboa

[Bug 114953] acpi_fakekey sends events to wrong evdev device

2007-05-15 Thread dynamotwain
Public bug reported: Binary package hint: acpi-support On my system (kernel sources 2.6.20) the event device mappings are as follows: /dev/input/event0 --> Power Button (FF) /dev/input/event1 --> Sleep Button (CM) /dev/input/event3 --> Logitech USB Gaming Mouse /dev/input/event4 --> AT Translated