summaryrefslogtreecommitdiffstats
path: root/client/x11
Commit message (Collapse)AuthorAgeFilesLines
* client: menu: make RedWindow::set_menu() return an error-code (#758260)Uri Lublin2011-12-211-1/+2
| | | | | | | | | | | RedWindow::set_menu() can fail (on Windows when in fullscreen mode). For Windows spice-client, when in fullscreen mode, the system-menu is NULL. Returns 0 upon success, non-0 (currently only -1) upon failure. (cherry picked from commit 24d5852611c3d5be3ba824af64cd5a3356b82b9c) (seperator vs separator --> a small typo that got fixed)
* client: add xinerama supportArnon Gilboa2011-11-132-0/+149
| | | | | | | | | | | | | | | | | | | | RHEL-6 Bugzilla: 695323 cherry-picked from qspice commit 003667ac99beeec9b330a07bc3569c59a96d4588 which fixes RHEL-5 541566 with merge of the one line qspice fix to SPICE_REQUIRES: 9f3fe4755f11044a45c4b21148466a997fcbf735 spice: fixed reference to xinerama pkg config file (Xinerama.pc=>xinerama.pc) Author: Yonit Halperin <yhalperi@redhat.com> (cherry picked from master, commit a30d96faa49bca73f9c6000c4123a8ffb996ee1b) Conflicts: client/Makefile.am
* fix infinite loop in resolution changeMarc-André Lureau2011-09-201-1/+7
| | | | | | | | | | | | After hours of investigation, I am a bit clueless.. It seems XRR is sending us spurious ScreenChangeNotify in a loop. So we keep calling init_monitors(), which creates new platform_win etc.. Although none of the clients seems to be resetting the screen (checked all XRRSet..). The fact that we create many platform_win looks like a bug to me, and indeed, it seems to help if we reuse the same platform_win over the various init_monitors() calls. Fixes rhbz #692833
* fix 2 X11 related leaksChristophe Fergeau2011-09-202-4/+8
|
* x11: don't return freed memory from get_clipboardChristophe Fergeau2011-07-211-2/+6
| | | | | | | | | | | | There is a double free in client/x11/platform.cpp. In get_selection(), in the exit: case with ret_val == -1 and data != NULL, *data_ret (which is returned to the caller) has already been assigned "data", so it will be pointing to freed memory when "data" is XFree'd'. Then in handle_selection_notify, get_selection_free is called on this pointer, which causes a double free. When the length of the read data = 0, set the returned value to NULL, this way subsequent free attempts will be a noop. Fixes RH bug #710461
* client: match delete[] with new[]Christophe Fergeau2011-07-211-1/+1
| | | | | vinfo in x11/platform.cpp is allocated using new[] so it needs to be freed with delete[]
* gl: remove unused variablesChristophe Fergeau2011-07-211-6/+0
| | | | gcc 4.6 warned about these.
* gl: use correct pixman accessor for image dataChristophe Fergeau2011-07-211-1/+1
| | | | | | | | | Commit 774e5bd36f4 changed - dest->source.pixmap.x_image->data + + (uint8_t *)pixman_image_get_stride(dest->source.pixmap.pixman_image) + The correct accessor to use is pixman_image_get_data. Thanks to gcc 4.6 for warning about a "different size" int to pointer conversion.
* Fixes compilation error of Spice Client (Linux/X11) with OpenGL enabled ↵Thomas Tyminski2011-07-211-3/+3
| | | | modified: client/x11/red_window.cpp
* spicec-x11: Work around a bug in xselHans de Goede2011-03-231-1/+3
| | | | | | | | | | | | | | | | | | | | Although ICCCM 2.2. Responsibilities of the Selection Owner: http://tronche.com/gui/x/icccm/sec-2.html#s-2.2 Clearly states (about selection notify events): The owner should set the specified selection, target, time, and property arguments to the values received in the SelectionRequest event. xsel sets the selection notify event target member to the incr atom when it is going to send the clipboard data incremental, rather then setting it to the UTF8_STRING atom (which was the target of the SelectionRequest). Work around this (esp as it is likely other programs may get this wrong too) and accept the incr atom as a valid target in a selection notify event. This fixes Alon's test with running: python -c "print list(range(1000))" | xsel -i -b on the client.
* spicec-x11: Don't crash on apps sending bad atoms as TARGETSHans de Goede2011-03-231-12/+16
| | | | | | | | | Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property, causing spicec to exit because of an XError. This patch makes spicec survive this scenario. For more info on the xsel bug, see: https://bugzilla.redhat.com/show_bug.cgi?id=690214
* x11: Use _exit rather then exit on X errors (rhbz#680763)Hans de Goede2011-03-011-2/+2
| | | | | | | This avoids us trying to restore the original resolution when we're fullscreen and an X error happens. As restoring fullscreen is a bad idea then as this involves making more X calls, which can get us stuck (in side an XLockDisplay call for example).
* spicec: Remove spice-client watermark (rhbz#662450)Hans de Goede2011-02-024-1035/+0
| | | | | | | | | This patch stops us from drawing the spice client watermark at the top of the virtual machine view. We have had requests through several channels to remove this as it has little added value, and is seen as annoying by some. Given that we now also have a bugzilla for this I think it is time we really remove it. (cherry picked from commit 392ed65dda1a28c85f04ebb09924c6ce83dbdf2b)
* client/server: warning fixes (gcc 4.6.0)Alon Levy2011-01-271-2/+5
| | | | | gcc 4.6.0 added "[-Werror=unused-but-set-variable]", this and the next few fixes tend to that. Mostly harmless.
* client: CEGUI: search for CEGUI-0.6 to work in F15 (rawhide)Alon Levy2011-01-191-0/+2
|
* spicec-x11: Let the window manager place our window the 1st time (rhbz#662407)Hans de Goede2010-12-162-1/+8
| | | | | | | | | | | | | | | | | | | | | | | The problem is that RedWindow::show calls the XLib MoveWindow function on the window after it has been mapped, moving it to the location in _show_pos. This is seen by the window manager as the application saying I know exactly where I want my window to be placed, don't do placing for me. Which causes the client window to always be shown at pos 0x0, even though that may not be the best location. What this patch does is: 1) It makes RedWindow::show not call MoveWindow when a window is first created normally and then shown 2) It makes RedWindow::show still call MoveWindow when: -when the window has been shown before, and was hidden for some reason (controller interface), and is now being re-shown so that it ends up being re-shown at its old position -when the window is a fullscreen window (screen.cpp always calls move on the window before showing it to set its position) -when the user switch from windowed mode -> fullscreen -> windowed mode again, to make sure that the windowed mode window is shown in the same position as before switching to fullscreen mode
* spicec-x11: Add a class hint to our window managet hintsHans de Goede2010-12-161-1/+10
| | | | | | This helps people who want to tell their windowmanager to do something special with spicec, like make it sticky, or whatever, see: https://bugzilla.redhat.com/show_bug.cgi?id=662452#c4
* smartcard: configure option --enable-smartcardAlon Levy2010-12-071-0/+9
|
* spicec-x11: Fix unhandled exception: no window proc crash (rhbz#655836)Hans de Goede2010-11-231-1/+9
| | | | | | | | | | | | | When XIM + ibus is in use XIM creates an invisible window for its own purposes, we sometimes get a _GTK_LOAD_ICONTHEMES ClientMessage event on this window. Since this window was not explicitly created by spicec, it does not have a Window Context (with the event handling function for the window in question) set. This would cause spicec to throw an unhandled exception and exit. This patch replaces the exception throwing with silently ignoring ClientMessage events on Windows without a Context and logging a warning for other event types.
* spicec-x11: Fix modifier keys getting stuck (rhbz#655048)Hans de Goede2010-11-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently modifier keys (ctrl, alt) can get stuck when using the x11 client. To reproduce under gnome: -focus the client window without causing it to grab the keyborad (click on the title bar not the window) -press crlt + alt + right arrow to switch virtual desktop -press crlt + alt + left arrow to switch back -notice ctrl + alt are stuck pressed What is happening here is: -We get a focus out event, caused by the hotkey combi key grab, focus event notify mode == NotifyGrab, and release all keys -> good -We get another focus out event, as we really loose the focus. notify mode == NotifyWhileGrabbed, which we ignore as we already lost focus before -We get a focus in event, as the focus is returning to us, but we don't really have the focus yet, as the hotkey combi key grab is still active (ie ctrl + alt are still pressed). We now sync the vm's modifier key state with the current X-server state, telling the vm ctrl + alt are pressed. Note we do this by directly reading the X-server keyboard status, we are not getting any key press events from the X-server -> bad -We get another focus in event, as we really get the focus back, notify mode == NotifyUngrab. We ignore this one as already have gained the focus before. If we were to sync the vm modifier state here, all would be well we would no longer see the modifier keys pressed, or if we would we would get a release event when they get released (testing has shown both). The solution here is to ignore the first focus in event, and do the modifier sync on the second focus in event, or more in general to ignore focus events where notify mode == NotifyWhileGrabbed.
* spicec-x11: Add a few missing XLockDisplay calls (rhbz#654265)Hans de Goede2010-11-171-0/+6
| | | | | The XIM functions end up waiting for a reply from the server, so they need locking around them. Idem for the XLookupString call.
* spicec-x11: Listen for selection owner window destroy / close events tooHans de Goede2010-10-281-3/+15
| | | | | These rarely happen as most apps have the decency to do a SetSelectionOwner None before exiting. But some do not, so listen for these too.
* spicec-x11: Do not set _NET_WM_USER_TIME to 0 on startupHans de Goede2010-10-252-5/+7
| | | | Setting _NET_WM_USER_TIME to 0 means we do not want focus, not good.
* Remove no longer used wstring_printf functionsHans de Goede2010-10-211-18/+0
|
* client: Interpret the title control message as utf8 instead of unicode16Hans de Goede2010-10-211-4/+4
| | | | | | | The activex browser plugin is sending unicode16 text, where as the xpi one is sending utf8 text. After discussing this on irc we've decided that utf8 is what we want to use. So the client (this patch), and the activex will be changed to expect resp. send utf8 text as the title.
* spicec-x11: Fix window management under KDEHans de Goede2010-10-182-0/+13
| | | | | | | | | | | | | | There were 2 issues with window management under KDE 1) When an app does its own focus management like we do, kwin expects an explicit raise for the app to get to the top, so we did have focus, but would have other windows (partially) covering the client window -> do a raise after setting focus to ourselves 2) When switching from fullscreen <-> window, we unmap and remap our window, then set focus to ourselves. kwin thinks this means we're trying to steal the focus without the user asking for it. This patch makes us set the _NET_WM_USER_TIME property on our window, this helps kwin's focus stealing code to see that we are really not stealing the focus, just responding to a user event.
* spicec-x11: Change WmSizeHints in fullscreen modeHans de Goede2010-10-182-21/+38
| | | | | | Some window managers will ignore the fullscreen hint, unless WmSizeHints allow them to resize the window so that they can give it the size of the roo-window. This fixes fullscreen mode in compiz.
* spicec-x11: Add missing XLockDisplay around XRRSet* callsHans de Goede2010-10-181-0/+10
| | | | | | XRRSet* calls wait for a XReply, so add a missing XLockDisplay, this fixes a hang (due to a race so not always) when switching between windowed and fullscreen mode.
* spicec: add controllerArnon Gilboa2010-10-181-0/+2
| | | | | | | | | | | Spice client controller enables external control (e.g., by XPI or ActiveX) of the client functionality. The controller protocol enables setting parameters (host, port, sport, pwd, secure channels, disabled channels, title, menus, hotkeys etc.), connecting the server, showing and hiding the client etc. The controller is based on the cross-platform named pipe.
* spicec: add foreign menuArnon Gilboa2010-10-181-0/+2
| | | | | | | | | Spice foreign menu enables external control of the client menu. The foreignmenu protocol enables an external application to: add a submenu, set its title, clear it, add/modify/remove an item etc. Foreign menu is based on the cross-platform named pipe.
* spicec-x11: add support for image copy and pasteHans de Goede2010-10-151-56/+70
|
* Replace epoll with select in X clientAlexander Larsson2010-10-122-218/+97
| | | | | | | | The use of epoll in the client is totally overkill in terms of scalability, and its a problem for portability. The OSX port converts this to use select, but keeps some of the old complexities in the code. This new patch makes it simpler and look much more like the windows code.
* spicec-x11: Put locks around xlib calls which wait for a replyHans de Goede2010-10-114-44/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since libX11-1.3.4 the multi-threading handling code of libX11 has been changed, see: http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=933aee1d5c53b0cc7d608011a29188b594c8d70b This causes several issues. One of them is the display inside the client not getting updated when there are no XEvents being generated, this is caused by the following part of the referenced commit message: Caveats: - If one thread is waiting for events and another thread tries to read a reply, both will hang until an event arrives. Previously, if this happened it might work sometimes, but otherwise would trigger either an assertion failure or a permanent hang. We were depending on the otherwise behavior and apparently were lucky. This can be seen by starting F14 in runlevel 3 and then doing startx and not touching the mouse / keyb afterwards. Once you move the mouse (generate an event you see the UI contents being updated but not before. Another thing both I and Alon (iirc) have seen are hangs where 2 threads are stuck in XSync waiting for a reply simultaneously. This might be related to libxcb version, according to the libX11 commit a libxcb newer then 1.6 was needed, and my system had 1.5 at the time I saw this after updating to libxcb 1.7 I can no longer reproduce. This patch tackles both problems (and is needed for the 1st one indepently of the 2nd one possibly being fixed) by adding XLockDisplay calls around all libX11 calls which wait for a reply or an event.
* spicec-x11: Drop annoying useless warningHans de Goede2010-10-061-1/+0
| | | | | | Every time an events comes past where the Window is None (which happens about once every 5 minutes or so), this annoying "invalid window" message gets printed. Remove it!
* spicec-x11: Remove a race window in selection ownership release codeHans de Goede2010-10-061-0/+8
| | | | | | | | | | | Well almost remove it, it was possible that another x11 app would acquire selection ownership, and we would receive a release message from the agent before having processed the xselection ownership change event. Then we would set the selection owner to none, overriding the new owner. As the comment in the patch indicates there still is a minute window left where something similar can happen after this patch. Nothing we can do about that (I blame the libX11 selection API).
* spicec: Move setting of clipboard_owner to guest to platform codeHans de Goede2010-10-061-2/+8
| | | | | | | | | | | | | | Atleast under x11 there is a race condition when setting the clipboard owner to guest from the RedClient code rather then doing it in Platform. After the XSetSelectionOwner() in Platform::on_clipboard_grab(), which runs from the main message loop thread, the x11 event thread can receive a SelectionRequest event from another x11 app, before the RedClient code has set the clipboard owner, which will trigger the owner != guest check in the SelectionRequest event handling code. By moving the setting of the owner in to Platform::on_clipboard_grab() it gets protected by the clipboard lock, which closes this tiny race.
* spicec-x11: make get_clipboard_type handle the None AtomHans de Goede2010-10-041-0/+3
|
* spicec-x11: protect against recursive incr propertiesHans de Goede2010-10-041-0/+4
|
* spicec-x11: If the clipboard was large return the memory to the systemHans de Goede2010-10-041-1/+8
|
* spicec-x11: use malloc / free / realloc for clipboard dataHans de Goede2010-10-041-19/+7
| | | | | | As we need a realloc function it is better to use malloc / free / realloc then to diy, esp. as realloc can grow the buffer without needing a memcpy.
* spicec-x11: Use a queue for XSelectionRequest eventsHans de Goede2010-10-041-59/+119
| | | | | | | | | | | XSelectionRequest events must be answered in the order they were received. But for TARGETS request we can answer directly, where as other requests need to go through the agent. This causes us to handle things out of order, and this can cause us to have more then one requets outstanding with the agent, which is also not what we want. So this patch introduces a queue for XSelectionRequest events, causing us to handle them 1 at a time and always in order.
* spicec-x11: handle multiple types per grabHans de Goede2010-10-041-55/+99
| | | | | And also handle many x11 targets (ie utf8 variants) to a single agent type mapping.
* spicec-x11: Add XFlush calls were neededHans de Goede2010-10-041-0/+10
| | | | | | | | Since we do not always "pump" libX11's event loop by calling XPending (we only call XPending when there is data to read from the display fd), we must always explictly flush any outstanding requests. This patch adds a whole bunch of missing XFlush calls.
* spicec-x11: Force processing of ownerchange event when releasing the cbHans de Goede2010-10-041-0/+13
| | | | | | | | | | | | Make sure we process the XFixesSetSelectionOwnerNotify event caused by us setting the clipboard owner to none, directly after setting the owner to none. Otherwise we may end up changing the clipboard owner to none, after it has already been re-owned because the XFixesSetSelectionOwnerNotify event to owner none is event is still pending when we set the new owner, and then changes the owner back to none once processed messing up our clipboard ownership state tracking. I saw this happening when doing copy twice in succession inside the guest.
* spicec-x11: Request targets from new clipboard ownerHans de Goede2010-10-041-123/+240
| | | | | | | | | | | | | | | Request targets from new clipboard owner, rather then assuming UTF-8 (not entirely complete yet, the last pieces will be in another patch). Atleast as important this code unifies the selection getting code for incr and non incr getting of selection data so that it can be used for both getting regular selection data and for getting targets selection data. This also fixes a big bug in the (I believe untested sofar) incr support code which was interpreting the contents of PropertyNotify events as XSelectionEvents rather then as XpropertyEvents which are completely differen structs!
* spicec-x11: remove clipboard_changer hackHans de Goede2010-10-031-19/+21
| | | | | | | Instead of keeping a flag, we can and should simply check wether the new owner reported in the event it us or not. Also check for the new owner being none and send a clipboard_release when that is the case (through set_clipboard_owner(owner_none)).
* Keep track of clipboard ownershipHans de Goede2010-10-021-0/+13
| | | | | | | | | | | | | Given that all clipboard handling is async, it is possible to for example receive a request for clipboard data from the agent while the client no longer owns the clipboard (ie a VD_AGENT_CLIPBOARD_RELEASE message is in transit to the agent). Thus it is necessary to keep track of our notion of clipboard ownership and check received clipboard messages (both from other apps on the client machine and from the agent) to see if they match our notion and if not drop, or in case were a counter message is expected nack the clipboard message.
* Rename platform clipboard handling functionsHans de Goede2010-10-021-4/+4
| | | | | | | | | | Rename the 4 platform clipboard functions which get called upon receival of an agent clipboard message to on_clipboard_* The old set_clipboard_* names were confusing as they suggest being a class property setter (like set_event_listener) rather then event handler, and set_clipboard_owner was causing a name conflict with the next patch in this series.
* Change VD_AGENT_CLIPBOARD_GRAB to an array of typesHans de Goede2010-10-011-5/+7
| | | | | | | A clipboard owner can indicate that it can supply the data the clipboard owns in multiple formats, so make the data passed with a VD_AGENT_CLIPBOARD_GRAB message an array of types rather then a single type.
* Call intern_atoms() earlierHans de Goede2010-10-011-2/+2
| | | | | We call XFixesSelectSelectionInput with the clipboard_atom, so we musr initialize the atoms before calling XFixesSelectSelectionInput.
generated by cgit (git 2.34.1) at 2024-06-10 00:05:42 +0000