hay guys why isn't XOpenDisplay()'s argument const char?

Is it safe to regard it as const char? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s

Re: xrandr: cannot find output 0x95

On 10/05/2016 03:08 AM, Michel Dänzer wrote: > On 04/10/16 09:40 PM, John Lewis wrote: >> It was the R7 360 that was causing the issue. Dual screens work just >> fine with Intel HD Graphics 4000. > Please attach the Xorg log file corresponding to the problem with the > Radeon GPU. > > It is now

Re: Update symbol/lk - xkb_symbols "us" variant

Looks right to me, we'll have to see what the xkeyboard-config folks say. -alan- On 10/ 5/16 09:55 AM, JC Ahangama wrote: Mr. Coopersmith, Did I do it right this time, please? https://bugs.freedesktop.org/show_bug.cgi?id=98098 I appreciate your nudging me along the right path.

Re: Problem with xorg-server-1.14.5

Hi, I can't use Xorg 1.13.x because for make Fedora 18 MR2 I need to use Xorg 1.14.5 ... For now I remove Xorg 1.13.x, and install Xorg 1.14.5, before I use both of Xorg ( 1.13.3-3 and 1.14.5 ). With new Xorg I can't start command startx. Best regards, Anteja Vuk - Macek Software Engineer

Re: Problem with xorg-server-1.14.5

Anteja Vuk Macek composed on 2016-10-05 14:30 (UTC+0200): I can't use Xorg 1.13.x because for make Fedora 18 MR2 I need to use Xorg 1.14.5 ... For now I remove Xorg 1.13.x, and install Xorg 1.14.5, before I use both of Xorg ( 1.13.3-3 and 1.14.5 ). With new Xorg I can't start command

Re: Need help understanding X server freeze

On Thu, Oct 06, 2016 at 12:31:59AM +0530, jeetu.gol...@gmail.com wrote: Can you think of something else we can try so we can further pinpoint where the problem lies or any thoughts at all on the above? Only more wild guesses, maybe input/event handling? GTK_IM_MODULE=xim

Re: xrandr: cannot find output 0x95

On 04/10/16 09:40 PM, John Lewis wrote: > It was the R7 360 that was causing the issue. Dual screens work just > fine with Intel HD Graphics 4000. Please attach the Xorg log file corresponding to the problem with the Radeon GPU. -- Earthling Michel Dänzer |

Re: Problem with xorg-server-1.14.5

Hi, On 4 October 2016 at 12:56, Anteja Vuk Macek wrote: > I try to install Fedora 18 MR2 - KDE , for that I need to install > xorg-server-1.14.5 ... I download from > http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.14.5.tar.gz. > > I configure and

Re: Problem with xorg-server-1.14.5

Hi On 5 October 2016 at 08:56, Anteja Vuk Macek wrote: > I know that Fedora 18 is old, but only for fedora 18 intel has ISP driver. Right, but my point was that you may want to use Xorg which ships with Fedora 18 (iirc, Fedora 18 ships with Xorg 1.13.x) rather than

Update symbol/lk - xkb_symbols "us" variant

I am repeating my request that I obviously did not send to the right place. Please implement the following change to the xkb_symbols "us" variant in the symbols/lk file. Thank you: REPLACE these two rows: key { [ d, D, q ] }; key { [ eth, ETH, VoidSymbol ] }; WITH these two: key { [ eth,

Re: xrandr: cannot find output 0x95

On Wed, Oct 5, 2016 at 7:54 AM, John Lewis wrote: > On 10/05/2016 03:08 AM, Michel Dänzer wrote: >> On 04/10/16 09:40 PM, John Lewis wrote: >>> It was the R7 360 that was causing the issue. Dual screens work just >>> fine with Intel HD Graphics 4000. >> Please attach the Xorg

NVidia GTX 980 Fedora vs older kernels

I've tried exploring this on forums and such without answer. I can't find a reason why my 980 GTX will work on Fedora but not Ubuntu or Linux Mint. The major difference I spot is a kernel version difference? Currently running mint w/o my 980 ZG Wolfe

Re: Update symbol/lk - xkb_symbols "us" variant

Mr. Coopersmith, Did I do it right this time, please? https://bugs.freedesktop.org/show_bug.cgi?id=98098 I appreciate your nudging me along the right path. Regards, JC On 10/5/2016 10:17 AM, JC Ahangama wrote: Thank you ever so much, Alan. I am reading them. JC On 10/5/2016 9:37 AM,

Re: hay guys why isn't XOpenDisplay()'s argument const char?

On 10/ 4/16 07:48 PM, Ashe Goulding wrote: Is it safe to regard it as const char? Since it's declared as const char, yes: #ifndef _Xconst #define _Xconst const #endif /* _Xconst */ extern Display *XOpenDisplay( _Xconst char* /* display_name */ ); (The ifdef used to be much more

Re: Update symbol/lk - xkb_symbols "us" variant

Hi,  I'm going to say to file a bug in bugzilla when I found this link  https://www.freedesktop.org/wiki/Software/XKeyboardConfig/Rules/ https://bugs.freedesktop.org/enter_bug.cgi?product=xkeyboard-config Using bugzilla, you will contact directly the maintainers and also your request won't be

Re: Update symbol/lk - xkb_symbols "us" variant

Thank you ever so much, Alan. I am reading them. JC On 10/5/2016 9:37 AM, Alan Coopersmith wrote: You are still not sending it to the right place - the XKB keymaps are maintained by the Xkeyboard-config project, which has it's own mailing lists, bug trackers, etc. See

Re: hay guys why isn't XOpenDisplay()'s argument const char?

On Wed, 2016-10-05 at 11:48 +0900, Ashe Goulding wrote: > Is it safe to regard it as const char? Yes. libX11 predates the wide availability of C89, so it tends not to include things like 'const' in function signatures. - ajax ___ xorg@lists.x.org:

Re: NVidia GTX 980 Fedora vs older kernels

Hi, To take a pure stab at this, not only ( probably ) does the open driver NOT support that one in older kernels ( binary blobs etc etc ). I wonder if something internal in the Kernel is needed also ( dependency ) for the Nvidia driver should you go that route. Regards On Wed, Oct 5, 2016

Re: Need help understanding X server freeze

Hi Thomas, I had the opportunity to run more tests based on your suggestion. The following are my findings : - LIBGL_ALWAYS_INDIRECT=1 LIBGL_ALWAYS_SOFTWARE=1 LIBGL_DRI3_DISABLE=1 These environment variables do not seem to have made any difference. I was still getting the desktop freeze with

Re: Need help understanding X server freeze

jeetu.gol...@gmail.com composed on 2016-10-06 00:31 (UTC+0530): Can you think of something else we can try so we can further pinpoint where the problem lies or any thoughts at all on the above? Try a substantially different environment, one without GDM, and as little of GTK as possible

Re: [PATCH xserver] dix: Bump MAXHASHSIZE for the resource db

Adam Jackson writes: > From: Roberto Ragusa > > [This was originally a workaround for a client-side resource leak: > > http://lists.freedesktop.org/archives/xorg-devel/2012-November/034555.html > > Obviously that's a broken app, but the performance

Bug#523972: xserver-xorg-video-radeon:

Package: xserver-xorg-video-radeon Version: 1:7.5.0-1 Followup-For: Bug #523972 I had similar issues with an R7 360. I have more information on this thread. https://lists.x.org/archives/xorg/2016-September/058291.html ___ xorg-driver-ati mailing list

[Bug 97987] xf86-video-ati-7.7.1: "(EE) No devices detected.", ppc

https://bugs.freedesktop.org/show_bug.cgi?id=97987 --- Comment #7 from erhar...@mailbox.org --- I built a new kernel and added following config options: CONFIG_VGA_ARB=y, CONFIG_FB_RADEON=m, CONFIG_DEVTMPFS_MOUNT=y. I removed: CONFIG_FB_OF, CONFIG_FB_SIMPLE. Still activated is;

[Bug 97987] xf86-video-ati-7.7.1: "(EE) No devices detected.", ppc

https://bugs.freedesktop.org/show_bug.cgi?id=97987 --- Comment #8 from erhar...@mailbox.org --- Created attachment 127041 --> https://bugs.freedesktop.org/attachment.cgi?id=127041=edit xorg.log_v2 -- You are receiving this mail because: You are the assignee for the

[Bug 97987] xf86-video-ati-7.7.1: "(EE) No devices detected.", ppc

https://bugs.freedesktop.org/show_bug.cgi?id=97987 --- Comment #9 from Michel Dänzer --- (In reply to erhard_f from comment #7) > [ 10.851080] radeonfb (:f0:10.0): ATI Radeon 4150 "AP" > [ 10.851081] radeonfb_pci_register END > [ 12.484886] [drm] radeon kernel

Re: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues

Hi, On 05-10-16 11:45, Hans de Goede wrote: Hi, On 05-10-16 11:41, Michel Dänzer wrote: From: Michel Dänzer I wanted to enable HW cursors on PRIME slave screens in our drivers, but noticed that a few things aren't quite right yet. The series is ordered from the most

[PATCH xserver 2/3] xf86Cursor: Use CursoreRec::bits->x/yhot in xf86SetCursor

From: Michel Dänzer xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens. Fixes intermittent incorrect HW cursor position on PRIME slave screens when switching between cursors with different hotspot positions. Also hoist the hotspot translation out from

[PATCH xserver 3/3] xf86Cursor: Take the input lock in xf86Set/MoveCursor

From: Michel Dänzer Prevents the HW cursor from intermittently jumping around when the cursor image is changed while the cursor is being moved. This is hardly noticeable in normal operation but can be quite confusing when stepping through these codepaths in a debugger.

Re: [PATCH xserver] glamor: Use eglGetPlatformDisplayEXT not eglGetDisplay

On 4 October 2016 at 18:34, Adam Jackson wrote: > eglGetDisplay forces the implementation to guess which kind of display > it's been handed. glvnd does something different from Mesa, and in > general it's impossible for the library to get this right. Instead use > the API where

[PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues

From: Michel Dänzer I wanted to enable HW cursors on PRIME slave screens in our drivers, but noticed that a few things aren't quite right yet. The series is ordered from the most obvious problem to more subtle ones. Patches 1 & 2 fix incorrect positioning of the HW

[PATCH xserver 1/3] xf86Cursor: Use CursoreRec::bits->x/yhot in xf86MoveCursor

From: Michel Dänzer xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens. Fixes incorrect HW cursor position on PRIME slave screens. Also hoist the hotspot translation out from xf86ScreenMoveCursor to xf86MoveCursor, since the hotspot position is a property of

Re: Request changes in Compose.pre

Good day! Sorry for noise, but I'm discouraged by silence. Maybe I need send patch by another address or maybe I doing wrong something... Please give me a tips how I may do it correctly. On Tue, 4 Oct 2016 15:52:05 +0300 "Victor V. Kustov" wrote: > Good day! > > Please approve

Re: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues

Hi, On 05-10-16 11:41, Michel Dänzer wrote: From: Michel Dänzer I wanted to enable HW cursors on PRIME slave screens in our drivers, but noticed that a few things aren't quite right yet. The series is ordered from the most obvious problem to more subtle ones. Patches

Re: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues

On 05/10/16 07:05 PM, Hans de Goede wrote: > On 05-10-16 11:45, Hans de Goede wrote: >> On 05-10-16 11:41, Michel Dänzer wrote: >>> From: Michel Dänzer >>> >>> I wanted to enable HW cursors on PRIME slave screens in our drivers, but >>> noticed that a few things aren't

Re: [PATCH xserver] glamor: Use eglGetPlatformDisplayEXT not eglGetDisplay

Hi, On 04-10-16 19:34, Adam Jackson wrote: eglGetDisplay forces the implementation to guess which kind of display it's been handed. glvnd does something different from Mesa, and in general it's impossible for the library to get this right. Instead use the API where you specify what kind of

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

On 04/10/16 17:45, Hans de Goede wrote: If been working for 7 days on a row now to get 1.19 in shape for Fedora 25, so I'm afraid that the v2 of this patch I'm working on is going to be a take it or leave it offer from my pov. You are of course more then welcome to improve upon the patch

Re: [PATCH libX11 1/2] The validation of server responses avoids out of boundary accesses.

Hi all, Sorry I didn't get a chance to look at these before they went public... On Sun, Sep 25, 2016 at 22:50:40 +0200, Matthieu Herrb wrote: > From: Tobias Stoeckmann > > v2: FontNames.c return a NULL list whenever a single > length field from the server is incohent.

[PATCH v2 xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu

Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu" introduced a regression as the computed pixmap offset would not match the actual coordinates and write data elsewhere in memory causing a segfault in fbBltOne(). Translate the pixmap coordinates so that the data is read and written

Re: [PATCH libXi] Properly validate server responses.

On Sun, Sep 25, 2016 at 22:50:43 +0200, Matthieu Herrb wrote: > From: Tobias Stoeckmann > > By validating length fields from server responses, out of boundary > accesses and endless loops can be mitigated. > > Signed-off-by: Tobias Stoeckmann >

[PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path

From: Michel Dänzer Fixes make check with out-of-tree builds. Signed-off-by: Michel Dänzer --- test/scripts/xvfb-piglit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/scripts/xvfb-piglit.sh

[PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal

When a fd is removed dev->state gets set to device_state_removed, if the fd then gets re-added before InputThreadDoWork() deals with the removal, the InputThreadDevice struct gets reused, but its state would stay device_state_removed, so it would still get removed on the first InputThreadDoWork()

[PATCH xf86-input-libinput] Fix crash when using threaded input and the first device goes away

When the xserver uses threaded input, it keeps a pointer to the InputInfo passed into xf86AddEnabledDevice and calls pointer->read_input on events. But when the first enabled device goes away the pInfo we've passed into xf86AddEnabledDevice gets freed and eventually pInfo->read_input gets

Re: [PATCH xf86-input-libinput] Fix crash when using threaded input and the first device goes away

Hi, On 05-10-16 15:31, Hans de Goede wrote: When the xserver uses threaded input, it keeps a pointer to the InputInfo passed into xf86AddEnabledDevice and calls pointer->read_input on events. But when the first enabled device goes away the pInfo we've passed into xf86AddEnabledDevice gets

[PATCH xserver] glamor: Use eglGetPlatformDisplay{,EXT} if we can

eglGetDisplay forces the implementation to guess which kind of display it's been handed. glvnd does something different from Mesa, and in general it's impossible for the library to get this right. Add a new inline that gets the logic right, and works around a quirk in epoxy. Signed-off-by: Adam

Re: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path

Michel Dänzer writes: > From: Michel Dänzer > > Fixes make check with out-of-tree builds. > > Signed-off-by: Michel Dänzer Reviewed-by: Keith Packard -- -keith signature.asc Description: PGP signature

[PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present

If we're never painting anything in the window, we probably don't need to map it. Signed-off-by: Keith Packard --- hw/kdrive/ephyr/hostx.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c index

[Bug 98097] New: [Regression, bissected] [EXA, TearFree] Visual corruption

https://bugs.freedesktop.org/show_bug.cgi?id=98097 Bug ID: 98097 Summary: [Regression, bissected] [EXA, TearFree] Visual corruption Product: xorg Version: git Hardware: Other OS: All Status: NEW

Re: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal

Hans de Goede writes: > When a fd is removed dev->state gets set to device_state_removed, > if the fd then gets re-added before InputThreadDoWork() deals with > the removal, the InputThreadDevice struct gets reused, but its > state would stay device_state_removed, so it

Re: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present

Keith Packard writes: > If we're never painting anything in the window, we probably don't need > to map it. > > Signed-off-by: Keith Packard Drop the extern ephyr_glamor_gles2 and it's: Reviewed-by: Eric Anholt signature.asc

Re: [PATCH xserver 01/14 v2] dix: Introduce CursorWarpedTo vfunc in Screen

On Tue, 2016-09-13 at 15:16 +0800, Jonas Ådahl wrote: > This new vfunc will be called, if set, after a client has issued a > WarpPointer request. This is necessary for implementing pointer warp > emulation in Xwayland. > > Signed-off-by: Jonas Ådahl > Reviewed-by: Peter

Re: [PATCH xserver 0/2] xwayland touch handling fixes

On Tue, 2016-09-27 at 19:03 +0200, Carlos Garnacho wrote: > Hi! > > I'm sending a couple of fixes to fix touch handling in wayland. The > first patch makes the XYToWindow proc handler friendlier to touch-driven > pointer emulation (and possibly other pointer-driving devices in the > future with

Re: [PATCH v2 xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu

On Wed, 2016-10-05 at 08:36 +0200, Olivier Fourdan wrote: > Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu" > introduced a regression as the computed pixmap offset would not match > the actual coordinates and write data elsewhere in memory causing a > segfault in fbBltOne(). > >

Re: [PATCH xserver] glamor: Use eglGetPlatformDisplay{, EXT} if we can

Adam Jackson writes: > eglGetDisplay forces the implementation to guess which kind of display > it's been handed. glvnd does something different from Mesa, and in > general it's impossible for the library to get this right. Add a new > inline that gets the logic right, and works

Re: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path

Michel Dänzer writes: > From: Michel Dänzer > > Fixes make check with out-of-tree builds. > > Signed-off-by: Michel Dänzer > --- > test/scripts/xvfb-piglit.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [PATCH 1/3] glx: drisw is not accelerated IGLX, reflect that in log messages

On Thu, 2016-09-29 at 18:41 +0100, Emil Velikov wrote: > The messages from glxdricommon.c (used by drisw) still have the A, but > at least we're don't have it locally. > > Cc: Adam Jackson > Signed-off-by: Emil Velikov Series merged (with fixup for

Re: [PATCH 1/4] configure.ac: default to DRI=yes on solaris platforms

On Thu, 2016-09-29 at 18:35 +0100, Emil Velikov wrote: > Afaict there's little-to-no reason/way one would want xserver without > DRI support on Solaris platforms. > > This will allow us to simplify/fix all the libdrm detection in the next > commit. Series merged (with trivial fixup for

Re: [PATCH xserver 1/3] xfree86: Immediately handle failure to set HW cursor, v5

On Fri, 2016-09-30 at 17:55 +0200, Michael Thayer wrote: > > > v5: Updated the patch to apply to current git HEAD, split up into two > patches (server and modesetting driver) and adjusted the code slightly > to match surrounding code.  I also removed the new exported function >

Re: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path

On Wed, 2016-10-05 at 10:34 -0700, Eric Anholt wrote: > Reviewed-by: Eric Anholt Merged: remote: I: patch #113692 updated using rev 95d3980c7c991b2cc8dcadac173635641ae15865. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver

Re: [PATCH xserver] glamor: Use eglGetPlatformDisplay{, EXT} if we can

On Wed, 2016-10-05 at 10:29 -0700, Eric Anholt wrote: > > Reviewed-by: Eric Anholt Merged: remote: I: patch #113802 updated using rev f4a41155479e68bf55740c1dfffafc78e4c02087. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver    

Re: [PATCH xserver 1/3] xfree86: Immediately handle failure to set HW cursor, v5

Hello Adam, On 05.10.2016 21:33, Adam Jackson wrote: On Fri, 2016-09-30 at 17:55 +0200, Michael Thayer wrote: v5: Updated the patch to apply to current git HEAD, split up into two patches (server and modesetting driver) and adjusted the code slightly to match surrounding code. I also

Re: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present

On Wed, Oct 5, 2016 at 09:42:19 -0700, Keith Packard wrote: > If we're never painting anything in the window, we probably don't need > to map it. > > Signed-off-by: Keith Packard > --- > hw/kdrive/ephyr/hostx.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) >

Re: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present

Julien Cristau writes: > The extern ephyr_glamor_skip_present declaration should probably live in > ephyr_glamor_glx.h so mismatches between it and ephyr_glamor_glx.c are > caught. Agreed; I was following the existing practice (and being a bit lazy). -- -keith