[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)
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, AwnHotspon, AwnBar, etc would all need to be notified of configuration changes (they currently aren't) and then deal with them correctly. You would have the same problems if you toggled the force_monitorm, monitor_width, or panel_mode settings before my patch. In Neil's trunk rewrite, AwnSettings goes away and everything that actually cares about the settings has its own notify function such that the correct behavior you and I both desire can be obtained... but with the infrastructure currently in trunk, it's just not feasible without a huge amount of effort that ultimately boils down to one of the changes in the trunk rewrite: properly responding to configuration changes. -- Incorrect screen positioning when using multiple displays (TwinView) https://bugs.launchpad.net/bugs/248769 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)
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-random-breakage', and it looks like the positioning fixes would be relatively straightforward and much cleaner. Basically, all Neil would have to do is add 'x' and 'y' properties to the AwnMonitor, move all the monitor-related stuff from AwmSettings to AwmMonitor, use x,y in awn-window:position_window. The strut related code looks like practically a drop-in replacement, although it'd need generalized for all four edges. Everything else is probably irrelevant to the new branch; if I had known, I would have based my patch against it. -- Incorrect screen positioning when using multiple displays (TwinView) https://bugs.launchpad.net/bugs/248769 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)
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 been purposely excluded in the past because they were considered 'internal'-only, despite being exposed from the library. 2. GObject-ify AwnSettings: It needs to be done at some point. * Having a nice singleton to maintain settings in a central location is a nice convenience. Having to break ABI for each setting you change or remove is not. * GTK+ has hit this same issue, which has prevented them from adding some features because it changes struts defined in public headers. * Accessor functions or GObject properties don't have this limitation. * A central settings manager that refreshes external updates is no good if its clients have to poll it for changes. GObject's "notify" signal is a trivially implemented solution that fits in with the rest of the GOBject-based codebase * ABI for the AwnSettings struct has already been broken twice in the past 4 months * Theoretically, since a maximum of one instance of AwnSettings will exist, there is no harm to not pairing g_object_unref calls with awn_settings_new calls; it's just a convenience for memleak debugging with Valgrind. * The next step would be to create accessors or properties for all the fields in AwnWidget and seal the members of the struct with GSEAL a'la GTK. Then after a major release with GSEAL enabled to give external applets time to do things right, move all the settings fields in the struct to a private struct instead of exposing it to the world. 3: Showing panel later after position is set: * Don't show the window before setting the position ourselves * Otherwise WM position AWN in some random place (possibly depending on mouse position) before we immediately move it to another location. * GTK was just going to put the window on the default screen anyway, so get the default screen without requiring the window to be realized first. 4. Use monitor.x and monitor.y when positioning windows * The change is simple: add monitor.x to the x value, and similar for y. * It's only so invasive because there's so much duplicated code in static functions in each of the .c files for the various windows. 5: Removal of AwnMonitor: It's not in libawn, but only in the source tree for one window that wasn't actually even using it. 6: Remove deprecated functions: the alternatives are functional equivalents and have been around since Gtk 2.0 7. Awn Applet dialog placement: use the monitor bounding box rather than 0..screenWidth 8. Deprecate awn_get_settings or not. Having two functions that do the exact same thing is pointless. Deprecate it like GTK+ does and leave it in, but conditionally compiled. This way you don't break ABI, but people know better than to use it and have a better chance of their code working as-is in the future. 9. autogen.sh changes: harmless unless you expect autogen.sh --prefix /usr to put files in /usr/local All in all, the only API and ABI incompatible changes I made were in removing the force_monitor, monitor_width, and monitor_height fields from the AwnSettings struct, none of which any external applet has an reason to depend on, especially considering they had a tendency to be unrealistic forced values for TwinView/Xinerama users. I didn't even touch upon the other ugliness I found in the source tree. There are static functions in src/ that were copy-pasted from one file to another that should be in say src/awn-window-shared.c for awn-bar, awn-hotspot, awn-main, awn-panel, and awn-window to use. Worse, there are non-singleton GObjects that store instance-specific values as global values! Even worse, some of them aren't static and pollute the global namespace. In the end, such clutter only makes programs harder to maintain and make changes like these appear more invasive than they really are. -- Incorrect screen positioning when using multiple displays (TwinView) https://bugs.launchpad.net/bugs/248769 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)
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 1 place instead of 3. * Don't assume the top-left corner of the desired monitor is (0,0) when placing windows * Set strut values that actually conform to spec (relative to overall screen edge, not monitor edge) * Remove all force_* settings in favor of one monitor_num setting * Add a 'monitor number' spinbox to the Bar Appearance tab of awn-manager to update the monitor_num setting * Automatically update if GTK receives a "monitors-changed" due to screen hotplugging With these changes, no more algebra is required to calculate unrealistic values for force_width and force_height to get the bar to appear on a second monitor. Nor does it require manual changes if your a laptop user and only occasionally have a external monitor attached. It does fix setting the the struts for users with multiple monitors of multiple resolutions in a horizontal configuration. It may or may not fix setting struts for internal edges in metacity or other WMs... but if it does, it's non-standard behavior in the WM and shouldn't be relied upon. ** Attachment added: "Real multiple monitor support for AWN" http://launchpadlibrarian.net/18703014/awn-multimonitor.bundle -- Incorrect screen positioning when using multiple displays (TwinView) https://bugs.launchpad.net/bugs/248769 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 248769] Re: Incorrect screen positioning when using multiple displays (TwinView)
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, the edge in common between your external monitor and your laptop's screen. 5 years ago when the specification for supporting such struts on multiple monitors was designed, it was unfortunately decided to limit struts to be defined only on the overall virtual screen's dimensions, not relative to any specific monitors in order to keep things a little more backwards compatible. (http://markmail.org/message/ojtfzu6ce5fhr3mp#query:_net_wm_strut_partial%20internal%20edge+page:1+mid:ojtfzu6ce5fhr3mp+state:results) The last attempt to fix this was in 2004, but died off from lack of interest (http://markmail.org/message/igxshkvtoiftxxaz#query:_net_wm_strut_partial%20internal%20edge+page:1+mid:svlu42opykargpej+state:results). With the advent of LCD displays with resolutions of 2560x1600, there is a much more significant need for supporting docks on internal edges. With a mjaor distribution like Ubuntu pressing, maybe the specs will be updated to support such a feature. That said, if the functionality you desire worked before, either you were placing AWN on your bottom monitor or it was a bug with your window manager (Metacity, judging from the screenshots) -- Incorrect screen positioning when using multiple displays (TwinView) https://bugs.launchpad.net/bugs/248769 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 114953] Re: acpi_fakekey sends events to wrong evdev device
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" Option "XkbRules" "xorg" EndSection There's nothing there to limit input to a specific device. I'm not the only person to have this problem either. http://blog.eikke.com/index.php/ikke/2007/04/28/how_to_fix_your_acpi_buttons_the_hackish However, I'm now running 2.6.22, and 'kbd' and 'event0' handle the power button now so the original version works as expected again. # cat /proc/bus/input/devices I: Bus=0019 Vendor= Product=0002 Version= N: Name="Power Button (FF)" P: Phys=button_power/button/input0 S: Sysfs=/class/input/input0 U: Uniq= H: Handlers=kbd event0 B: EV=3 B: KEY=10 0 0 0 All in all, it appears to have been a kernel issue. -- acpi_fakekey sends events to wrong evdev device https://bugs.launchpad.net/bugs/114953 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 114953] Re: acpi_fakekey sends events to wrong evdev device
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 keyboard to be found instead of power buttons. Also, it makes acpi_fakekey accept a 2nd argument... an overriding evdev device file to use instead of the auto-detect mechanism that might be useful in the case of multiple keyboards and multiple X-servers running on the same machine. ** Attachment added: "Patch to make acpi_fakekey correctly determine keyboard or take it directly from the commandline" http://librarian.launchpad.net/7662837/acpi_fakekey-correct-keyboard.patch -- acpi_fakekey sends events to wrong evdev device https://bugs.launchpad.net/bugs/114953 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 114953] acpi_fakekey sends events to wrong evdev device
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 Set 2 keyboard /dev/input/event5 --> PC Speaker /dev/input/event6 --> SynPS/2 Synaptics TouchPad Since the Power Button evdev interface reports having KEY_POWER available and KEY_POWER < BTN_MISC, acpi_fakekey as it currently exists sends the keys to the power button interface instead of the keyboard X is listening on. acpi_fakekey needs to be more selective as to what it considers a keyboard. ** Affects: acpi-support (Ubuntu) Importance: Undecided Status: Unconfirmed -- acpi_fakekey sends events to wrong evdev device https://bugs.launchpad.net/bugs/114953 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
