summaryrefslogtreecommitdiffstats
path: root/client/x11
Commit message (Collapse)AuthorAgeFilesLines
* client: add xinerama supportArnon Gilboa2011-11-141-0/+147
| | | | | | | | | | | | | | 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>
* client/x11: reset screen positions in XMonitor::do_restoreChristophe Fergeau2011-10-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | XMonitor::do_restore (called for example when going out of fullscreen) restore the screen resolution to its previous state, but it doesn't take care of repositioning the screen to their previous position, which is one of the advantages of using randr 1.2. Since MultyMonScreen::restore handles all of this for us, just call it to restore the monitor position/resolutions to their previous settings. Before doing any changes, MultyMonScreen::restore checks if there's something to do, so calling it once per monitor won't be an issue, the resolution/position will only be set the first time. This has the side-effect of fixing bug #693431. This bug occurs when closing the client after the client went in and out of fullscreen. MultyMonScreen::~MultyMonScreen calls MultyMonScreen::restore, which decides to change the screen positions since they were lost when going to fullscreen because XMonitor::restore didn't restore the positions. After this change, the positions will be properly restored and MultyMonScreen::restore won't be needlessly called upon client shutdown.
* client/x11: fix mode setting in MultyMonScreen::restoreChristophe Fergeau2011-10-051-7/+1
| | | | | | | | | MultyMonScreen::restore changes the X11 Screen resolution, but it doesn't use MultyMonScreen::set_size. This means MultyMonScreen::_width and MultyMonScreen::_height don't get updated to reflect the new resolution settings, which could cause issues later on. Until now this was safe since the only caller of MultyMonScreen::restore was MultyMonScreen destructor.
* client/x11: fix typos (finde => find)Christophe Fergeau2011-10-051-7/+7
|
* fix bug #692833Marc-André Lureau2011-09-011-1/+7
|
* use Xkb to get keyboard modifier maskChristophe Fergeau2011-08-171-23/+2
| | | | | | | | | | | | | | To be able to enable/disable keyboard leds on X11, we need to query the X server for which mask correspond to which led (NumLock, CapsLock). So far this was done using XKeysymToKeycode and iterating over X modifier mapping. Xkb provides XkbKeysymToModifiers for this purpose, and since we're using Xkb anyway, it makes more sense to use it. At some point, on my Fedora 15 box, XKeysymToKeycode was returning NoSymbol for CapsLock and NumLock leading to spicec not being able to change the keyboard leds when qemu tells it to. However, I couldn't reproduce this when I tried again :-/
* fix 2 X11 related leaksChristophe Fergeau2011-08-152-4/+8
|
* Fix typo: treshold -> thresholdLiang Guo2011-08-021-1/+1
|
* x11: don't return freed memory from get_clipboardChristophe Fergeau2011-07-181-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-181-1/+1
| | | | | vinfo in x11/platform.cpp is allocated using new[] so it needs to be freed with delete[]
* client: remove unused mb() macroChristophe Fergeau2011-05-031-6/+0
|
* s/USE_OGL/USE_OPENGLChristophe Fergeau2011-05-036-58/+58
| | | | This is more explicit about what it does, and not much longer
* add #include <config.h> to all source filesChristophe Fergeau2011-05-0315-0/+45
| | | | | | | | When using config.h, it must be the very first include in all source files since it contains #define that may change the compilation process (eg libc structure layout changes when it's used to enable large file support on 32 bit x86 archs). This commit adds it at the beginning of all .c and .cpp files
* autotools: refactor the whole build machineryChristophe Fergeau2011-05-032-228/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | spice Makefile.am setup is a bit confusing, with source file names being listed several times in different Makefile.am (generally, once in EXTRA_DIST and another time in another Makefile.am in _SOURCES). The client binaries are built by client/x11/Makefile.am, which means recursing into client, then into x11 to finally build spicec. This Makefile.am is also referencing files from common/ and client/, which is a bit unusual with autotools. This patch attempts to simplify the build process to get something more usual from an autotools point of view. The source from common/ are compiled into a libtool convenience library, which the server and the client links against which avoids referencing source files from common/ when building the server and the client. The client is built in client/Makefile.am and directly builds files from x11/ windows/ and gui/ if needed (without recursing in these subdirectories). This makes the build simpler to understand, and also makes it possible to list source files once, which avoids potential make distcheck breakage when adding new files. There is a regression in this patch with respect to sw_canvas/gl_canvas/gdi_canvas. They should be built with different preprocessor #defines resulting in different behaviour of the canvas for the client and the server. However, this is not currently the case, both the client and the server will use the same code for now (which probably means one of them is broken). This will be fixed in a subsequent commit. make distcheck passes, but compilation on windows using the autotools build system hasn't been tested, which means it's likely to be broken. It shouldn't be too hard ot fix it though, just let me know of any issues with this.
* client: remove c++ wrappersChristophe Fergeau2011-05-021-12/+12
| | | | | | | | client/ contains several .cpp file which only #include a .c file of the same name. This is unusual and seems to only be done to get C++ name mangling on the symbols defined in the C file. Now that all headers files in common/ use extern "C", these wrappers are no longer useful.
* gl: remove unused variablesChristophe Fergeau2011-04-081-6/+0
| | | | gcc 4.6 warned about these.
* gl: use correct pixman accessor for image dataChristophe Fergeau2011-04-081-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.
* 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).
* client/server: warning fixes (gcc 4.6.0)Alon Levy2011-01-251-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-051-0/+2
|
* Fixes compilation error of Spice Client (Linux/X11) with OpenGL enabled ↵Thomas Tyminski2011-01-051-3/+3
| | | | modified: client/x11/red_window.cpp
* spicec: Remove spice-client watermark (rhbz#662450)Hans de Goede2010-12-164-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.
* 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.
generated by cgit (git 2.34.1) at 2024-11-12 04:06:39 +0000