[ANNOUNCE] xcb-util 0.3.0
xcb-util 0.3.0 is now available. git tag 0.3.0 Changelog = Arnaud Fontaine (15): [icccm] Make xcb_get_text_property() public as it might be useful for [property] Add missing xcb_get_any_property_unchecked(). [atom] Move '*discriminated_atom*' functions from icccm to atom [icccm] Make xcb_get_text_property() and functions relying on it [icccm] Make xcb_get_wm_transient_for() asynchronous and document the code. [icccm] Make xcb_get_wm_size_hints() and xcb_get_wm_normal_hints() [icccm] Make xcb_get_wm_hints() asynchronous, remove useless functions [icccm] Make xcb_get_wm_protocols() asynchronous and document the [icccm] Fix namespace according to XCB code in general. [icccm] Add copyright notices. [icccm] Add functions to get WM_CLASS property. [icccm] Avoid InternAtom request. [icccm] Comment and indent the code properly. [icccm] Bump library version number to 0.3.0. wm: tag_t was renamed to xcb_atom_fast_tag_t. Henning Sten (2): return on error to avoid null dereference in assert add doxygen documentation markup for XCB_EVENT_RESPONSE_TYPE_MASK macro Julien Danjou (15): icccm: fix memory leak in xcb_get_wm_hints() icccm: fix wrong variable initialization icccm: free reply in wm hints retrieval atom: prefix functions and types atom: bump version info atom: include xcb headers property: rewrite property handler interface icccm: allow information retrieval from reply event: rework, rename and add some documentation event: define XCB_EVENT_RESPONSE_TYPE_MASK reply: rework and add some documentation Remove NEWS doc: add various authors, remove old todo item doc: enable doxygen doc in various submodule icccm: introduce xcb_get_wm_transient_for_from_reply Keith Packard (4): Add image conversion test case for 'make check' xcb_mask must not be zero when n == 32. Rework image format conversion code to pass test_swap test case. Add test_swap to image/.gitignore Download http://xcb.freedesktop.org/dist/xcb-util-0.3.0.tar.gz md5: aec0148e8ce5ee7a64675223b3344537 sha1: 9090dabaa4d5631a00ed8b4435d982925739494b http://xcb.freedesktop.org/dist/xcb-util-0.3.0.tar.bz2 md5: 5f2188492a7d12142d83f73cf0054c59 sha1: 9c534cbd498620e8f70cbe3d989eebcff824b9eb Cheers, -- Julien Danjou // ᐰ [EMAIL PROTECTED] http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] Stable pixman release 0.12.0 now available
A new major release 0.12.0 of the pixman library is now available. New features since 0.10.0 include: - New image formats with 10 bits per channel (Aaron Plattner) - SSE2 optimizations for many operations (André Tupinambá) - Opacity based optimizations for operators (Antoine Azar) - Altivec optimizations for many operations (Luca Barbato) - A 32 bit region implementation (Søren Sandmann) Thanks to everyone who contributed to this release, including Aaron Plattner, Alan Coopersmith, André Tupinambá, Antoine Azar, Behdad Esfahbod, Benjamin Otte, Damien Carbery, David Sharp, Dimitrios Apostolou, Frédéric Plourde, Ginn Chen, Jeff Muizelaar, Julien Cristau, Luca Barbato, Luo Jinghua, Maximilian Grothusmann, Oswald Buddenhagen, Peter O'Gorman, Richard Hult, Søren Sandmann, Thomas Zimmermann, and Vladimir Vukicevic. Søren tar.gz: http://cairographics.org/releases/pixman-0.12.0.tar.gz http://xorg.freedesktop.org/archive/individual/lib/pixman-0.12.0.tar.gz tar.bz2: http://xorg.freedesktop.org/archive/individual/lib/pixman-0.12.0.tar.bz2 Hashes: MD5: 09357cc74975b01714e00c5899ea1881 pixman-0.12.0.tar.gz MD5: 494af78c1c7d825c9ad6815d7b91f17d pixman-0.12.0.tar.bz2 SHA1: 595487766c3814afeaaf18e1021b312dd546dfec pixman-0.12.0.tar.gz SHA1: 0c57c6c7e21e2545257068f52517c460e6e51ae4 pixman-0.12.0.tar.bz2 GPG signature: http://cairographics.org/releases/pixman-0.12.0.tar.gz.sha1.asc (signed by Søren Sandmann Pedersen [EMAIL PROTECTED]) Git: git://git.freedesktop.org/git/pixman tag: pixman-0.12.0 Log: Aaron Plattner (22): Fix test build when srcdir != builddir. Get rid of pixman_composeFunctions_accessors. Move combining macros into pixman-combine.c. Move combining routines into combine.inc and add a Perl rule to generate Tack 32 onto the ends of the combining function types. Replace hardcoded numbers and uint*_t in combine.inc. Generate 64-bit combining functions. Use a macro to append _accessors to things. Move the scanline buffer allocation logic into pixman_composite_rect_gene Split fetch/fetchPixel/store proc types into 32-bit and 64-bit versions. Add infrastructure for allocating wide scanline buffers. Not yet used. Use wide compositing functions when wide == 1. Fix wide alpha fetch macro. Add expand and contract functions to convert between ARGB8 and ARGB16. Add wide fetch/store functions. Add wide source picture, external alpha, and transformed image routines. Make expansion and contraction loops clearer. Take the source format into account in pixman_expand. Decide based on the image formats whether we need wide compositing. Use pixman_malloc_ab instead of plain malloc for the fbStore64_generic sc Add a lossy 32-bit generic pixel fetch function for wide surfaces. Add depth 30 formats to pixman_format_supported_source. Alan Coopersmith (1): Fix pixman/Makefile.am to work with Solaris make Andre Tupinamba (1): [sse2] Change pixman-sse to pass __mm128i args as pointers, so as not to André Tupinambá (4): Add SSE2 implementations of many compositing operations. Fix bug 16310 in the SSE2 fast path in function fbCompositeSolidMask_nx88 Fix SSE2 bug where x888 pixels were treated as Use CopyAreasse2, plus a compatibility fix Antoine Azar (1): Optimize operators based on source or dest opacity. Behdad Esfahbod (1): Fix fbCompositeSrc_x888xnxmmx to properly ignore source alpha Benjamin Otte (1): fix Altivec detection Damien Carbery (1): Add pixman-1-uninstalled.pc file David Sharp (1): pixman-sse.c: silence pointer-cast compiler warnings. Dimitrios Apostolou (1): Fix compilation on SGI Frederic Plourde (2): Add CopyAreammx fast path for argb32 SRC xrgb32 and abgr32 SRC xbgr32 Win32 Makefile fix Frédéric Plourde (1): Win32 build system fixes Ginn Chen (1): Use hidden attribute for private functions when compiling with Sun Studio Jeff Muizelaar (2): Comment FbByteMulAdd Speed up fbOver Julien Cristau (7): Remove prototype for nonexistent pixman_image_set_filter_params pixman-version.h is generated, don't distribute it Revert pixman-version.h is
Re: Building X
On Fri, 2008-09-19 at 15:02 +1000, Russell Shaw wrote: I think it would be a good idea if there was a default cursor present if nothing else. At least when using the ugly grey stipple. If you're using -br, the missing-cursor plan seems reasonable. Otherwise, it makes debugging X server startup a bit harder. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Russell Shaw wrote: Peter Hutterer wrote: On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote: I built X from git. I get a stippled background when X starts but the mouse cursor is invisible. The mouse is working because i tested it with xev. I built and installed in this order: commit e02f864fdf19a5ab1682336be343c57fdb69ef43 Author: Adam Jackson [EMAIL PROTECTED] Date: Wed Aug 20 13:24:03 2008 -0400 Suppress cursor display until the first XDefineCursor() request. Yes, this means the server will start without showing a cursor. Pretty much any application that wants to interact with the mouse will define cursors, so this essentially just delays showing it until gdm (or whatever) loads. Hi, That's somewhat interesting. A lot of old or simple X programs (and X tutorials) didn't call XDefineCursor() from what i've seen. When i ran xev (from git), the cursor didn't appear either. I'm testing X on a remote pc and so don't need xdm or any apps running on X. Any testing is simpler if the complications of xdm or a window manager are avoided. I think it would be a good idea if there was a default cursor present if nothing else. I realized that without a window manager you get an ugly black cross cursor which isn't real useful. X should've had a default arrow cursor. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
On Fri, Sep 19, 2008 at 04:44:51PM +1000, Russell Shaw wrote: I realized that without a window manager you get an ugly black cross cursor which isn't real useful. X should've had a default arrow cursor. X should've a lot of things. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Raw mouse input is distorted
Søren Hauberg wrote: Can I somehow force the evdev driver to only accept absolute events? I'll see if I can find the time to look into fixing the issue, as I guess it could be related to my problems. But like everybody else I'm in lack of time, so I'm not sure if it'll be doable. Adding an option would make the problem solveable in HAL, which isn't the worst place of all. Should be trivial. If that's the issue, you should find both relative and absolute axes mentioned in your xorg log. In xf86-input-evdev/evdev.c there's EvdevInit and EvdevProbe. The former could be used to place an option, the latter might give you insights how to mod your kernel module to get rid of relative stuff so you don't need to modify evdev. @Peter: It might make sense to suppress the relative bit if a absolute touchpad is found, or go prefer absolute on touchpads in EvdevInit(). How do you think about that? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
The latest Xorg and intel driver segfaults
Hello, I tried to run the latest Xserver and the Intel driver (both current git head). It segfaults at the startup: Core was generated by `/usr/local/X11R7.5/bin/Xorg :1.0'. Program terminated with signal 11, Segmentation fault. [New process 3191] #0 intel_nondrm_exec (bo=0x100aec0, used=16, priv=0x7fd81d35f270) at i830_batchbuffer.c:48 48 BEGIN_LP_RING(2); (gdb) where #0 intel_nondrm_exec (bo=0x100aec0, used=16, priv=0x7fd81d35f270) at i830_batchbuffer.c:48 #1 0x7fd81d13c1b4 in dri_fake_bo_exec (bo=0x100aec0, used=16, cliprects=0x0, num_cliprects=0, DR4=-1) at intel_bufmgr_fake.c:1216 #2 0x7fd81d35f0f8 in intel_batch_flush (pScrn=0xfd2910) at i830_batchbuffer.c:177 #3 0x7fd81d35ea7a in I830Sync (pScrn=0xfd2910) at i830_accel.c:195 #4 0x7fd81c4c678c in exaWaitSync (pScreen=0x10025d0) at exa.c:1049 #5 0x7fd81d36424d in i830_crtc_lock (crtc=0xfd7930) at i830_display.c:936 #6 0x004ac1cc in xf86CrtcSetMode (crtc=0xfd7930, mode=0xfd7a18, rotation=1, x=0, y=0) at xf86Crtc.c:253 #7 0x004aca17 in xf86SetDesiredModes (scrn=0xfd2910) at xf86Crtc.c:2342 #8 0x7fd81d36dac2 in I830EnterVT (scrnIndex=0, flags=value optimized out) at i830_driver.c:3678 #9 0x7fd81d36f24a in I830ScreenInit (scrnIndex=0, pScreen=0x10025d0, argc=value optimized out, argv=value optimized out) at i830_driver.c:3399 #10 0x00432ef6 in AddScreen (pfnInit=0x7fd81d36df70 I830ScreenInit, argc=2, argv=0x7fff28a51258) at main.c:695 #11 0x0046e411 in InitOutput (pScreenInfo=0x7dd260, argc=2, argv=0x7fff28a51258) at xf86Init.c:1090 #12 0x00433625 in main (argc=2, argv=0x7fff28a51258, envp=0x7fff28a51270) at main.c:315 (gdb) I'm not using the GEM kernel. -- Lukáš Hejtmánek ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
I would like to configure my laptop to use the big desktop feature (ATI)
Dear list, I have a problem understanding what I need to do to configure my xorg.conf to properly use my external CRT and Laptops LCD so that I can correctly use the Big Desktop feature to extend my desktop (when connected to the external monitor) using the CRT as the primary (left of laptop) display, and when I am not connected, to revert to single desktop using the LCD on the laptop. I am not sure if I have not, in my conquest for compiz, shot my config all to hell. Some System Info: $ uname -a Linux shb-laptop 2.6.24-1-686 #1 SMP Thu Jun 5 13:30:33 UTC 2008 i686 GNU/Linux glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No (LIBGL_ALWAYS_INDIRECT set) server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon X1400 OpenGL version string: 1.4 (2.1.7873 Release) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x2c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x2d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x2e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 None 0x2f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x30 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x31 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x32 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0
Re: Building X
On Thu, 2008-09-18 at 23:39 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 15:02 +1000, Russell Shaw wrote: I think it would be a good idea if there was a default cursor present if nothing else. At least when using the ugly grey stipple. If you're using -br, the missing-cursor plan seems reasonable. Otherwise, it makes debugging X server startup a bit harder. If you can come up with a way to distinguish 'started X by hand' from 'machine's being slow, wm isn't started yet', then git is standing by ready for patches. If you're debugging server startup, surely you're doing it with a breakpoint set on WaitForSomething(). - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP Docs...
On Thu, 2008-09-18 at 16:28 -0700, [EMAIL PROTECTED] wrote: Hi all, recently I was put in charge of creating a clean room implementation of the XDMCP protocol for our Apple Terminal Server product. This was done for various political and technical reasons which are beyond the scope of this email. I wanted to tell all of you that while I found the XDMCP.PS document helpful, I also found it lacking a little. So I started to document and create supplemental information for the XDMCP protocol and its current standards based implementation. You are welcome to reproduce and distribute the documents as a whole or in part as long as you give credit in your reproduced form to the company Aqua Connect and to me (Joseph Cohen). You can find these documents at: http://www.aquaconnect.net/?p=400 Sorry, no posts matched your criteria. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fix for damage protocol specification
On Thu, 2008-09-18 at 18:13 -0400, Owen Taylor wrote: Here's a tiny fix for the damage protocol specification Applied, thanks! - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
... I don't believe this anywhere near the functionality that I am talking about. If I am mistaken please elaborate on how to do it with xrandr. Regards, -Clay On Fri, Sep 19, 2008 at 8:13 AM, Alan Cox [EMAIL PROTECTED] wrote: So I guess basically my question is what would it take to do this, and is it possible? man xrandr No idea if the proprietary drivers support it but this all seems to just work with current Fedora/Xorg/Intel hardware. Only specific problem I'm aware of is that if the virtual desktop is 2048 pixels wide you currently get 2D but not 3D acceleration - which is being worked on. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
Well it certainly isn't a checkbox... and I haven't found any tutorials on it. It seems like it may need so driver cooperation too. Does X already have the ability to add viewpoints to an existing instance? Thanks, -Clay P.S. Should have been I don't believe this has on that last email... On Fri, Sep 19, 2008 at 8:35 AM, Marius Gedminas [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 08:06:34AM -0500, Clayton Shepard wrote: http://brainstorm.ubuntu.com/idea/11787/ Basically in a multiple monitor setup I would like each monitor to be a viewport to the same instance of X and same set of workspaces. Each monitor could view any available workspace independently of the other monitors. If two monitors are displaying the same workspace then their views are cloned. GDM and Compiz already handle windows larger than workspaces as well as windows spanning workspaces which would make this setup very, very, versatile. I think the brainstorm has a more elaborate description; hopefully you understand what I am trying to convey. So I guess basically my question is what would it take to do this, and is it possible? I'm sure Compiz could do this, in theory. (This is actually what I initially expected when I first started experimenting with dual-head.) Marius Gedminas -- C++ is a loaded machine gun helpfully pointed at your feet with the safety off. -- ChaosDiscord on Slashdot -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI06qYkVdEXeem148RAk0GAJwIiyduCqDcvDJ+2VhB/F3aHdx6RgCfcozp RxO/HekiBqkyz1kPTT6t1w0= =qDY6 -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
On Fri, 19 Sep 2008 08:57:13 -0500 Clayton Shepard [EMAIL PROTECTED] wrote: ... I don't believe this anywhere near the functionality that I am talking about. If I am mistaken please elaborate on how to do it with xrandr. Set the virtual desktop nice and large in size, define both displays as pointing to the same desktop and then xrandr will let you decide which rectangle of the display is on each monitor (and these may overlap) On Fedora you just select multihead in system-config-display to do this. Once you've got the virtual desktop then xrandr will let you move displays around with xrandr --output whatever --pos XxY You need drivers which support randr 1.2 and I believe currently you need a video card with multiple outputs - you can't do this across two cards, but that may have changed by now. Alan -- Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 4096 x 2048 VGA connected 1600x1200+1600+0 TMDS-1 connected 1600x1200+0+0 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
Yes, but that won't display the application bar on each monitor or allow you to rotate workspaces independently will it? Thanks, -Clay On Fri, Sep 19, 2008 at 9:11 AM, Alan Cox [EMAIL PROTECTED] wrote: On Fri, 19 Sep 2008 08:57:13 -0500 Clayton Shepard [EMAIL PROTECTED] wrote: ... I don't believe this anywhere near the functionality that I am talking about. If I am mistaken please elaborate on how to do it with xrandr. Set the virtual desktop nice and large in size, define both displays as pointing to the same desktop and then xrandr will let you decide which rectangle of the display is on each monitor (and these may overlap) On Fedora you just select multihead in system-config-display to do this. Once you've got the virtual desktop then xrandr will let you move displays around with xrandr --output whatever --pos XxY You need drivers which support randr 1.2 and I believe currently you need a video card with multiple outputs - you can't do this across two cards, but that may have changed by now. Alan -- Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 4096 x 2048 VGA connected 1600x1200+1600+0 TMDS-1 connected 1600x1200+0+0 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
Yes, but that won't display the application bar on each monitor or allow you to rotate workspaces independently will it? What gets displayed on each desktop depends what you put there. If it doesn't do what you want send the relevant application authors patches. As to rotation - yes xrandr lets you rotate or mirror displays individually. I don't know which drivers support individual rotation as I've no real need to rotate displays. Alan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xorg-server-1.5.0] keyb hang after starting q3
Peter Hutterer wrote: On Thu, Sep 18, 2008 at 11:51:47PM -0500, Tobias Jakobi wrote: After ioquake3 is started all keyb and mouse input stop. You can't move the cursor, you can't click. Switching to another application isn't possible, even switching to the VTs isn't possible. All input is simply dead. [...] I consider this a serious bug with the X input. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. [mi] EQ overflowing. The server is probably stuck in an infinite loop. [mi] mieqEnequeue: out-of-order valuator event; dropping. I think your server is probably stuck in an infinite loop :) Input is still coming in, but not being processed because something else is hogging the server. Why is the menu then rendered correctly? To be more precise. The menu isn't static, there is the moving q3 logo at the top. And this one is moving. And why am I not experiencing this with other applications (yet)? (EE) intel(0): underrun on pipe B! I blame the graphics driver. Sry, but this error message is originating from another source. Probably this one: http://bugs.gentoo.org/show_bug.cgi?id=236436 There was also a discussion on the ml about the intel flicker problem. I e.g. can reproduce this by simply calling xrandr (without parms). This also leaves this error msg in the log. So this is not input related. Cheers, Peter Greets, Tobias ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
I will play with this more, but I still am skeptical that it will do what I am describing. In the past when I tried this it seemed as though either each monitor displayed a separate set of workspaces (you couldn't have both monitors sharing workspaces), the application bar extended across both monitors as one one workspace, or the second monitor just added extra resolution to the workspace you were on. Thanks for your help, -Clay ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: A couple of composite fixes from Owen Taylor
On Thu, Sep 18, 2008 at 9:22 PM, Keith Packard [EMAIL PROTECTED] wrote: Owen Taylor has been poking at Composite for a while now and has helped uncover a couple of interesting corner cases. Here are two patches, the first is a correctness patch which fixes parent clip recomputation when windows move from automatic to manual redirection. The second is an optimization to eliminate descendent exposures on parent resize. -- [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Is there a reason why you didn't commit these patches? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
On Fri, Sep 19, 2008 at 09:08:49AM -0500, Clayton Shepard wrote: Well it certainly isn't a checkbox... and I haven't found any tutorials on it. I wasn't clear enough. Code can be written to make Compiz do this. I don't think it has been written yet. It seems like it may need so driver cooperation too. No; as a composition manager Compiz can deal with this without any extra help from X. Although input may be tricky, if you have the same workspace show on both monitors... Still, should be doable. Marius Gedminas -- 9. Okay, then, what do you think about syntactic noise in config files? [EMAIL PROTECTED]@!#([EMAIL PROTECTED]';,[EMAIL PROTECTED] -- http://open.nit.ca/wiki/index.php?page=RetchMail signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
OpenGL is free free free software
http://www.linux.com/feature/148339 SGI used their or later privilege to upgrade to the X11 licence. w00t! - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: A couple of composite fixes from Owen Taylor
On Fri, 2008-09-19 at 09:06 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 17:11 +0200, Maarten Maathuis wrote: Is there a reason why you didn't commit these patches? Owen hasn't tested the second patch yet. Also, it's nice to see if anyone has comments on the patch before they hit master. I've tested both patches and they work well as far as I can tell. (Of course, proving that they don't cause obscure problems elsewhere is a lot harder than proving that they fix the problems they were designed to fix.) Also, they make sense to me as patches. I guess I might quibble with the comment in the second one which makes it sounds like this has to do with exotic guffaw scrolling manipulations or something. /* No matter what happened to the parent window bits because of window * and bit gravity, the bits of redirected children are not affected * so no exposures are needed */ ? - Owen ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: OpenGL is free free free software
On Fri, 2008-09-19 at 17:54 +0100, David Gerard wrote: http://www.linux.com/feature/148339 SGI used their or later privilege to upgrade to the X11 licence. w00t! I've updated the server source in git to reflect FreeB 2.0. Older servers are exactly as free now, you just have to be aware that FreeB got updated. I don't see an update to the GLX Public License yet though. It's sort of implied in the press release that it's covered too, but the text here isn't changed: http://www.sgi.com/products/software/opensource/glx/license.html - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
On Fri, 2008-09-19 at 08:28 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 09:45 -0400, Adam Jackson wrote: On Thu, 2008-09-18 at 23:39 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 15:02 +1000, Russell Shaw wrote: I think it would be a good idea if there was a default cursor present if nothing else. At least when using the ugly grey stipple. If you're using -br, the missing-cursor plan seems reasonable. Otherwise, it makes debugging X server startup a bit harder. If you can come up with a way to distinguish 'started X by hand' from 'machine's being slow, wm isn't started yet', then git is standing by ready for patches. Just saying that if you ask for the ugly grey stipple, you should probably get the ugly X cursor too. You don't ask for the stipple though. It's the default. The protocol, by the way, does _not_ mandate the stipple. It says that the initial contents are some unspecified two-color pattern made of blackPixel and whitePixel. There is a weasel argument here that having zero white pixels still counts as two color I guess. Even if you don't like that argument, we are the keepers of the spec, there's no reason we can't relax that requirement. X -partylikeits1989 sounds just fine to me. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
build.sh updates
Couple enhancements to build.sh. The first patch simply adds Mesa and
libdrm support.
The second patch adds the capability to customize configure flags for
modules and components. It's done by passing in a file on the command
line which is in the following format:
all: --extra-config-flags-to-all-components
module: --extra-config-flags-for-just-this-module
module/component: --extra-config-flags-for-just-this-component
-Rob
CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute it. Please notify the sender by E-Mail at the address shown and delete the original message.
--- build.sh2008-09-08 23:02:36.613709784 -0400
+++ build.sh.addmesa2008-09-19 13:31:00.792075918 -0400
@@ -41,6 +41,12 @@
libxtrans) C=xtrans ;;
esac
;;
+mesa)
+case $C in
+drm) C=libdrm ;;
+mesa) C=Mesa ;;
+esac
+;;
pixman)
M=lib
C=pixman
@@ -387,7 +393,7 @@
build_mesa() {
build mesa drm
-#build mesa mesa
+build mesa mesa
}
# The server requires at least the following libraries:
--- build.sh2008-09-08 23:02:36.613709784 -0400
+++ build.sh.confflags 2008-09-19 13:37:58.900804394 -0400
@@ -137,6 +137,12 @@
MOD_SPECIFIC=--with-xcb=no
fi
+if test x$CONFFLGFILE != x test -e $CONFFLGFILE; then
+MOD_SPECIFIC=$MOD_SPECIFIC `grep all: $CONFFLGFILE | cut -d : -f 2-`
+MOD_SPECIFIC=$MOD_SPECIFIC `grep $1: $CONFFLGFILE | cut -d : -f 2-`
+MOD_SPECIFIC=$MOD_SPECIFIC `grep $1/$2: $CONFFLGFILE | cut -d : -f
2-`
+fi
+
LIB_FLAGS=
if test x$LIBDIR != x ; then
LIB_FLAGS=--libdir=${PREFIX}/${LIBDIR}
@@ -616,6 +622,7 @@
echo -a : do NOT run auto config tools (autogen.sh, configure)
echo -b : use .build.$HAVE_ARCH build directory
echo -c : run make clean in addition to others
+echo -C configure-flags-file : file with configure flags
echo -d : run make distcheck in addition to others
echo -D : run make dist in addition to others
echo -g : build with debug information
@@ -643,6 +650,10 @@
-c)
CLEAN=1
;;
+-C)
+ shift
+ CONFFLGFILE=$1
+ ;;
-d)
DISTCHECK=1
;;
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: events in evdev.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Jackson wrote: On Thu, 2008-09-18 at 09:24 -0700, Alan Coopersmith wrote: Chuck Robey wrote: Sorry, I can't parse what you wrote. You don't know where I heard that Xorg is Linux-only? Is that what you said? My understanding *had been* that Xorg was trying to be compatible with as many Unixes as possible, and specifically avoid being Linux only, which is why seeing the depth of Linuxcode that is in your flagship input driver, evdev, surprised me so. I uderstood, from Peter's mail, that I'm wrong there, and the use of Linux-only ocde in that flagship driver was deliberate. Simply really surprised me, that's all. Xorg is not Linux-only, but evdev is. On Solaris BSD, Xorg uses the xf86-input-keyboard xf86-input-mouse drivers instead. Both Solaris and BSD have very similar event APIs, afaik, and could easily have drivers for same. But they don't. Patches gratefully etc. - ajax I'm really rather curious where you got the idea that FreeBSD had something that looked even vaguely like the Linux events. I know that if you look at the FreeBSD man page EVENTHANDLER(9) you can see an event interface, but that one is intra-kernel, not exported to applications like the Linux one is. Using the event interface, like evdev does, takes away the portability. If I could find a FreeBSD applications-event interface ala Linux, I would be overjoyed, and immediately use it. The xf86_input_joystick interface is a way better example for how to write a driver than the evdev is (unless you're using Linux), because it compatibly brings in 3 different interfaces types, /including/ evdev. If it were me, that's the one I'd give newbies, not evdev. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjUBKgACgkQz62J6PPcoOkIzQCglxtdK6clIGMc8Ui1hXwhm1IR NocAn01KFXPda+CN23fx6DZXDf3YfbHX =jfyu -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: events in evdev.c
Both Solaris and BSD have very similar event APIs, afaik, and could easily have drivers for same. But they don't. Patches gratefully etc. - ajax I'm really rather curious where you got the idea that FreeBSD had something that looked even vaguely like the Linux events. I know that if you look at the FreeBSD man page EVENTHANDLER(9) you can see an event interface, but that one is intra-kernel, not exported to applications like the Linux one is. Using the event interface, like evdev does, takes away the portability. The xf86_input_joystick interface is a way better example for how to write a driver than the evdev is (unless you're using Linux), because it compatibly brings in 3 different interfaces types, /including/ evdev. If it were me, that's the one I'd give newbies, not evdev. BSD has the usbhid interface, which uses events as well. It's implemented in xf86-input-joystick's backend_bsd.c file and it's pretty generic (here of course trimmed for joystick use). Of course the interface is BSD-only (don't know about Solaris) but if the interfaces are somewhat compatible one could of course thing about wrapping it in the server, like the joystick driver does for itself. - Sascha signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: A couple of composite fixes from Owen Taylor
On Fri, Sep 19, 2008 at 7:44 PM, Owen Taylor [EMAIL PROTECTED] wrote: On Fri, 2008-09-19 at 09:06 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 17:11 +0200, Maarten Maathuis wrote: Is there a reason why you didn't commit these patches? Owen hasn't tested the second patch yet. Also, it's nice to see if anyone has comments on the patch before they hit master. I've tested both patches and they work well as far as I can tell. (Of course, proving that they don't cause obscure problems elsewhere is a lot harder than proving that they fix the problems they were designed to fix.) Also, they make sense to me as patches. I guess I might quibble with the comment in the second one which makes it sounds like this has to do with exotic guffaw scrolling manipulations or something. /* No matter what happened to the parent window bits because of window * and bit gravity, the bits of redirected children are not affected * so no exposures are needed */ ? - Owen If keithp wrote that comment, than perhaps he could improve the comment, because it's not very obvious to me what window gravity does. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: OpenGL is free free free software
Can anyone comment on the relationship between this and mesa? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: OpenGL is free free free software
John Tapsell johnflux at gmail.com writes: Can anyone comment on the relationship between this and mesa? Recalling from reading the Debian bug report that started this whole thing, this covers GLX (server side), I believe, at least as far as non-DFSG-free code already in the server. Mesa is a clean(ish)*-room implementation of the OpenGL client-side. * I'm pretty sure that as SGI has freed code under a suitable license it has been absorbed into Mesa. At any rate, the days of license problems with SGI's OpenGL code are fast becoming history. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: A couple of composite fixes from Owen Taylor
On Fri, 2008-09-19 at 13:44 -0400, Owen Taylor wrote: Thanks for checking things out; I will go ahead and push them now. I guess I might quibble with the comment in the second one which makes it sounds like this has to do with exotic guffaw scrolling manipulations or something. Older window systems would often just discard all window contents on resize. Adding well-defined bit and window gravity to X11 made it able to preserve window contents across resize in a predictable manner, and the whole adventure in SlideAndSizeWindow was designed to 'fix' what was once a fairly broken implementation of that. The recomputation of exposures is a fairly blunt instrument to apply in this case, but it was the easiest mechanism I could come up with at the time. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XDMCP Docs...
http://www.aquaconnect.net/?p=400 Sorry, no posts matched your criteria. I got the same error this morning at work, but tonight at home it appears to now be working okay. Pat --- On Fri, Sep 19, 2008 at 8:47 AM, Adam Jackson [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 16:28 -0700, [EMAIL PROTECTED] wrote: Hi all, recently I was put in charge of creating a clean room implementation of the XDMCP protocol for our Apple Terminal Server product. This was done for various political and technical reasons which are beyond the scope of this email. I wanted to tell all of you that while I found the XDMCP.PS document helpful, I also found it lacking a little. So I started to document and create supplemental information for the XDMCP protocol and its current standards based implementation. You are welcome to reproduce and distribute the documents as a whole or in part as long as you give credit in your reproduced form to the company Aqua Connect and to me (Joseph Cohen). You can find these documents at: http://www.aquaconnect.net/?p=400 Sorry, no posts matched your criteria. - ajax ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Keith Packard wrote: Yes, I'm cool with the black root background; nicer looking, conforming to the spec and everything. As a X user and occasional embedded programmer, might I suggest something with a pattern? Even if it's a X logo in the center, or just a shapeless blob, or a row and column of white pixels. Anything that is recognizable as the X root window. I've displayed random areas of memory before because my hardware framebuffer wasn't where I thought it was, and a black background was my clue that something was really wrong. Just my $0.01, what with the recession here in the US. --Yan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Keith Packard wrote: On Fri, 2008-09-19 at 13:52 -0400, Adam Jackson wrote: You don't ask for the stipple though. It's the default. My point was that if you want to avoid the vintage X appearance, you'd likely start the X server with a black root window instead of the ugly stipple, and we could hook the 'disable the cursor' mode to the same option. Does that seem like a reasonable combination? I just can't imagine any credible desktop environment wanting either the stipple or the X cursor. The protocol, by the way, does _not_ mandate the stipple. It says that the initial contents are some unspecified two-color pattern made of blackPixel and whitePixel. There is a weasel argument here that having zero white pixels still counts as two color I guess. Even if you don't like that argument, we are the keepers of the spec, there's no reason we can't relax that requirement. Yes, I'm cool with the black root background; nicer looking, conforming to the spec and everything. A good solution would be to just replace the black cross cursor bitmap with an arrow cursor that is visible by default. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Monitors, Same Workspaces
On Fri, 2008-09-19 at 10:01 -0500, Clayton Shepard wrote: I will play with this more, but I still am skeptical that it will do what I am describing. In the past when I tried this it seemed as though either each monitor displayed a separate set of workspaces (you couldn't have both monitors sharing workspaces), the application bar extended across both monitors as one one workspace, or the second monitor just added extra resolution to the workspace you were on. Then most likely you didn't compile your apps and toolkit with Xinerama support. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Radeon X700 Mobility: [mi] EQ overflowing ... server lockup
Hi all. I've been on the 'bleeding edge' ( git ) of mesa, xserver, xf86-video-ati friends for the past year or so ( on Gentoo ). I've got a Turion ( AMD64 ) processor ( running in 64-bit mode ), and a Radeon X700 Mobility. I updated everything about a week ago, and couldn't get into X at all - it locked my system hard and I had to power off ( magic SysRq keys didn't work ). I was going to move to Ubuntu when 8.10 came out, but since I had seemed to have broken my Gentoo system beyond my ability to repair it ( other than going back to xserver-1.4 ), I thought I'd try out a Ubuntu 8.10 beta release. Things didn't go so well ... It's using xserver-1.5 and mesa-7.1 ( sorry I don't know what version of xf86-video-ati ). I got into X the 1st 2 or 3 times with no problems, but would get lockups after the 1st 10 minutes or so. It looked like X was segfaulting and in the process of dropping back to the console, I'd get a corrupted display, as per my previous report ( bits of screen overlayed in different parts of the screen, and fading from one colour to another over time ... see my previous report for slightly more details ). The only time I managed to get into X and check out my /var/log/Xorg.log.old, it had a whole heap of this at the end: [mi] EQ overflowing. The server is probably stuck in an infinite loop Now ( without having changed anything ), I'm only getting lockups on entering X, exactly the same as I was on Gentoo. X gets to the point of showing the crosshair cursor, but before the stipple effect, and doesn't do anything. I can move the cursor, but *very* slowly. Can't SysRq. Can't drop to a console. Can't CTRL-ALT-DEL to reboot. Have to power off. I was using Ubuntu's generic xorg.conf, which is remarkably small and must make X detect everything. On Gentoo I had a much longer xorg.conf, and it wasn't detecting anything ( so it's not the detection stuff that's crashing ). The only change I made to Ubuntu's xorg.conf was to enable EXA - admittedly things went sour *after* this, but I haven't been able to switch back to XAA to test ( how do you stop Ubuntu from booting straight into X? ) So anyway, something is seriously borked, at least on my Radeon X700 Mobility. Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
