summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-10-13mutter: hack up the output setup configuration3.10-mst-tileDave Airlie1-7/+68
first time to run mutter hack up config to get the tiled monitor ordering right.
2014-10-13initial WIP - add multi monitorDave Airlie5-9/+163
this get maximising to work at least properly
2014-07-24background: Do not assume GLSL is availableAdel Gadllah1-1/+16
Some hardware does not support it causing crashes in cogl during paint. https://bugzilla.gnome.org/show_bug.cgi?id=733623
2014-04-22xrandr: ignore the error if setting the primary output failsAlberto Milone1-6/+11
Some drivers which support RandR 1.4 may not support setting or getting the primary output, therefore mutter should trap and ignore any relevant errors. The modesetting driver exposes this problem when used in combination with the nvidia binary driver using RandR 1.4 offloading. Also use a local display variable instead of calling meta_get_display () every time.
2014-04-10window-actor: Guard against %NULL frame maskFlorian Müllner1-1/+2
Creating a new cogl texture may fail, in which case the intent to free it will crash. While something is clearly wrong (insanely large window, oom, ...), crashing the WM is harsh and we should try to avoid it if at all possible, so carry on. https://bugzilla.gnome.org/show_bug.cgi?id=722266
2014-02-19Bump version to 3.10.4Florian Müllner2-1/+18
Update NEWS.
2014-02-15idle-monitor: avoid XSyncBadAlarm X errorRyan Lortie1-1/+1
If we fail to find the IDLETIME counter, then the alarm variable will be uninitialised. Most code paths are careful to check this before submitting XSync calls, but there is one check missing. https://bugzilla.gnome.org/show_bug.cgi?id=724364
2014-02-13window: don't set _NET_WM_FULLSCREEN_MONITORS to bogus valuesGiovanni Campagna2-17/+31
Prior to the DisplayConfig merge, we would set _NET_WM_FULLSCREEN_MONITORS to (unsigned)-1 when unset. After that, we would have invalid reads inside meta_screen_monitor_index_to_xinerama_index() (called with -1). The way I read the specification, the proper way to indicate that the window is back to fullscreen on all monitors is to remove the property, so do that. Also, add an assertion that meta_screne_monitor_index_to_xinerama_index() is doing the right thing. https://bugzilla.gnome.org/show_bug.cgi?id=724258
2014-02-06Update Arabic translationKhaled Hosny1-8/+8
2014-02-05updated kn.poShankar Prasad1-1835/+177
2014-02-05xrandr: Use specified output property name for backlight controlRobert Ancell2-4/+4
Backlight controls are set using the "BACKLIGHT" XRANDR output property. This should be "Backlight" according to the XRANDR spec [1]. Some drivers (Intel) export both properties and some only the specified property (nvidia). Users of drivers that only export the specified property cannot change their backlight using XRANDR. [1] http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt section 9.1 https://bugzilla.gnome.org/show_bug.cgi?id=723606
2014-02-02monitorManager: Fix logic bug in make_logical_configAdel Gadllah1-1/+1
The code that prevents the creation of multiple MonitorInfos for clones wasn't working due to using the wrong index when getting the already created info so fix that to use the correct one. https://bugzilla.gnome.org/show_bug.cgi?id=710610
2014-02-02window_actor: Remove the frame_messages timeout in destroyAdel Gadllah1-0/+6
Otherwise it might fire off later and cause a crash. https://bugzilla.gnome.org/show_bug.cgi?id=723468
2014-01-31window-actor: Fix unobscured_region handling when computing paint volumeAdel Gadllah1-1/+1
We currently ignore the unobscured region when we have mapped clones in meta_window_actor_process_damage and meta_window_actor_damage_all but use it unconditionally when computing the paint volume. This is wrong. We should ignore it there as well or we will end up with empty clones if the cloned window is completly obscured (like the tray icons in gnome-shell). https://bugzilla.gnome.org/show_bug.cgi?id=721596
2014-01-31window-actor: Fix optimization in get_paint_volumeJasper St. Pierre1-1/+5
We need to clip the paint volume to the unobscured region, not the other way around... https://bugzilla.gnome.org/show_bug.cgi?id=720630
2014-01-31window: Add "skip-taskbar" propertyFlorian Müllner1-0/+17
We currently only have a method to query the skip-taskbar hint. Add a corresponding property to allow listening for change notifications. https://bugzilla.gnome.org/show_bug.cgi?id=723307
2014-01-29constraints: CSD windows need to have their titlebar kept onscreen tooJasper St. Pierre1-1/+0
GTK+ CSD windows are considered undecorated by the code, so we should not force ourselves to only run on decorated windows. https://bugzilla.gnome.org/show_bug.cgi?id=719772
2014-01-15Bump version to 3.10.3Florian Müllner2-1/+17
Update NEWS.
2014-01-07window: don't grab server during calc_showingDaniel Drake1-7/+0
This grab was added in commit caf43a123f40d3a68599ac5453a79759b828e8f0 https://bugzilla.gnome.org/show_bug.cgi?id=381127 to minimize window flickering when switching workspaces. While this grab is held, some signals are emitted to the shell, which can lead to deadlocks (reproduced under Mali binary OpenGLESv2 drivers). Now that we are a compositing window manager, we do not have to worry about flickers, this grab should no longer be necessary. https://bugzilla.gnome.org/show_bug.cgi?id=721709
2014-01-06Reduce server grabs during window creationDaniel Drake3-12/+5
Remove some obvious server grabs from the window creation codepath, also ones that are taken at startup. During startup, there is no need to grab: we install the event handlers before querying for the already-existing windows, so there is no danger that we will 'lose' some window. We might try to create a window twice (if it comes back in the original query and then we get an event for it) but the code is already protected against such conditions. When windows are created later, we also do not need grabs, we just need appropriate error checking as the window may be destroyed at any time (or it may have already been destroyed). The stack tracker is unaffected here - as it listens to CreateNotify and DestroyNotify events and responds directly, the internal stack representation will always be consistent even if the window goes away while we are processing MapRequest or similar. https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-06meta_window_new: clean up error handlingDaniel Drake1-42/+20
The return code of XGetWindowAttributes() indicates whether an error was encountered or not. There is no need to specifically check the error trap. The trap around XAddToSaveSet() was superfluous. We have a global error trap to ignore any errors here, and there is no need to XSync() as GDK will later ignore the error asynchronously if one is raised. Also move common error exit path to an error label. https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-06screen: use stack tracker for initial window queryDaniel Drake1-8/+6
In meta_screen_manage_all_windows() we can use our own stack tracker to get the list of windows - no need to query X again. A copy is needed because the stack gets modified as part of the loop. Specifically, meta_stack_tracker_get_stack() at this time returns the predicted stack, and meta_window_new() performs a few operations (e.g. framing) which cause immediate changes to the predicted stack. https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-06frame: remove unnecessary server grabDaniel Drake1-13/+0
meta_window_ensure_frame() creates its own grab and has a comment claiming that it must be called under a grab too. But the reasoning given in the comment does not seem relevant here. We only frame non-override-redirect windows, so we are creating the frame in response to MapRequest. There is no way that the child could receive a MapNotify at this point, since that only happens much later, once we go through the CALC_SHOWING queue and call XMapWindow() from meta_window_show(). Remove the unnecessary grab. https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-06Discourage server grabsDaniel Drake1-1/+12
Server grabs are not as evil as you might expect, but there is agreement in that their usage should be limited. Server grabs can cause things to go rather wrong when mutter emits a signal while it has grabbed the server. If the receiver of that signal waits for a synchronous action performed by another client, then you have a deadlock. This happens with Mali binary GLESv2 drivers :( https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-06Remove meta_window_new_with_attrsDaniel Drake4-157/+85
The compositor code used to handle X windows that didn't have a corresponding MetaWindow (see commit d538690b), which is why the attribute query is separated. As that doesn't happen any more, we can clean up. No functional changes. Suggested by Owen Taylor. https://bugzilla.gnome.org/show_bug.cgi?id=721345
2013-12-24display: Don't leave focus on a window we are unmanaging when sending ↵Owen W. Taylor1-0/+19
WM_TAKE_FOCUS When we move focus elsewhere when unmanaging a window, we *need* to move the focus, so if the target is globally active, move the focus to the no-focus-window in anticipation that the focus will normally get moved to the right window when the target window responds to WM_TAKE_FOCUS. If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left on the no-focus-window, but there's no way to distinguish whether the app will respond or not. https://bugzilla.gnome.org/show_bug.cgi?id=711618
2013-12-24Be willing to unfocus the grab window when we are unmanaging itOwen W. Taylor1-1/+2
When we are unmanaging the grab window, we /need/ to unfocus it, so we shouldn't bail out early from meta_window_focus(). https://bugzilla.gnome.org/show_bug.cgi?id=711618
2013-12-18Fix problems with focus trackingOwen W. Taylor2-6/+27
When a client spontaneously focuses their window, perhaps in response to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial. Updating display->focus_serial in response to FocusOut then was causing us to ignore FocusIn and think that the focus was not on any window. We need to distinguish this spontaneous case from the case where we set the focus ourselves - when we set the focus ourselves, we're careful to combine the SetFocus with a property change so that we know definitively what focus events we have already accounted for. https://bugzilla.gnome.org/show_bug.cgi?id=720558
2013-12-16display: Fix checks for KeyPress/ButtonPressJasper St. Pierre1-1/+1
https://bugzilla.gnome.org/show_bug.cgi?id=720545
2013-12-09MetaWindowGroup: fix paint volumeOwen W. Taylor1-2/+21
In the past, MetaWindowGroup was allocated the size of the screen and painted the size of the screen because it contained the screen background, but now we also have the "top window group" which contains only popup windows, so the allocation doesn't properly reflect the paint bounds of the window group. Compute the paint bounds accurately from the children. https://bugzilla.gnome.org/show_bug.cgi?id=719669
2013-12-07Update Chinese simplified translation甘露(Gan Lu)1-579/+556
2013-12-04display: Don't focus the no-focus-window when sending WM_TAKE_FOCUS to a ↵Jasper St. Pierre1-19/+0
globally active window Clients like on-screen keyboards try not to take focus when the user clicks on their window by setting the Input hint to false. However, due to GTK+ and GDK bugs, the public API for setting the Input hint to false don't remove WM_TAKE_FOCUS from WM_PROTOCOLS, unintentionally putting them into Globally Active mode. These clients also expect that since they don't want to take focus, they want the focus to remain on the existing window. In this case, for clients like on-screen keyboards, it's so they can send synthesized keyboard events to the focused window. https://bugzilla.gnome.org/show_bug.cgi?id=710296
2013-11-14xrandr: use "hotplug_mode_update" propertyMarc-André Lureau4-21/+83
Use the "hotplug_mode_update" connector property indicating that the screen settings should be updated: get a new preferred mode on hotplug events to handle dynamic guest resizing (where you resize the host window and the guest resizes with it). https://bugzilla.gnome.org/show_bug.cgi?id=711216
2013-11-14Bump version to 3.10.2Florian Müllner2-1/+11
Update NEWS.
2013-11-04window: don't ignore resize button release event for move/resize actionsLionel Landwerlin1-1/+2
https://bugzilla.gnome.org/show_bug.cgi?id=710251
2013-10-25Updated Dutch translationReinout van Schouwen1-113/+121
2013-10-24Updated Greek translationEfstathios Iosifidis1-355/+309
2013-10-15Bump version to 3.10.1.1Florian Müllner2-1/+8
Update NEWS.
2013-10-15monitor-config: prevent assert that at least one output is connectedGiovanni Campagna1-0/+9
Apparently some connector technologies don't distinguish between on and off, and there might be valid use cases for running without any connected monitor. In that case, just avoid any configuration at all. https://bugzilla.gnome.org/show_bug.cgi?id=709009
2013-10-14Bump version to 3.10.1Florian Müllner2-1/+16
Update NEWS.
2013-10-13[l10n] Updated Catalan (Valencian) translationCarles Ferrando1-2634/+200
2013-10-13display: don't interrupt grab move/resize without modifiersLionel Landwerlin1-0/+1
The part of code dealing with move/resize grab in display.c is only responsible of this behavior when triggered with a modifier. So it shouldn't stop the move/resize behavior triggered from a mouse event without modifier on the title bar or sides of the window. https://bugzilla.gnome.org/show_bug.cgi?id=704759
2013-10-13window: don't process unrelated release eventsLionel Landwerlin1-37/+40
When processing button events related to moving/resizing the window, only the first button should be considered. https://bugzilla.gnome.org/show_bug.cgi?id=704759
2013-10-12Updated Dutch translation (work in progress)Reinout van Schouwen1-526/+484
2013-10-10shaped-texture: Use nearest-pixel interpolation if the texture is unscaledHans Petter Jansson1-0/+21
Use nearest-pixel interpolation if the texture is unscaled. This improves performance, especially with software rendering. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=708389
2013-10-09prefs: Fix introspection issuesJasper St. Pierre1-3/+3
2013-10-09stack: Never try to focus a DOCK windowJasper St. Pierre1-11/+1
2013-10-07meta-window-actor: Fix offset calculation in queue_send_frame_messages_timeoutAdel Gadllah1-1/+1
The current time offset calculation is wrong. It is supposed to calculate the offset between the current time and the "time where it message should be sent" (last_time + interval). Fix the math to actually do that. https://bugzilla.gnome.org/show_bug.cgi?id=709340
2013-10-07Update Arabic translationKhaled Hosny1-347/+301
2013-09-26MetaIdleMonitor: protect the monitor instance while calling destroy notifyGiovanni Campagna1-0/+2
The destroy notify for a DBus watch holds a reference to the IdleMonitor, but the IdleMonitorWatch object doesn't (it knows all watches will be destroyed before the monitor is, so it doesn't need one). This means that the DBus watch reference can be the only one keeping the IdleMonitor alive (expecially true for device idle monitors, which are only used by g-s-d/cursor), and that means that calling the destroy notify freezes the monitor (and the next X calls access garbage). https://bugzilla.gnome.org/show_bug.cgi?id=708420
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-28 11:23:11 +0000