testers needed for GX2 Xorg driver

the code at (https://gitlab.freedesktop.org/cbehan/xf86-video-geode/-/tree/improvements) for possible breakage on real GX2 hardware before we proceed with merging this. Thanks! Martin-Éric

Linux KMS driver for Geode LX

/fbrausse/geode-lx Help to polish the code and upgrade it for for merging at the LKML is welcome. Martin-Éric

Why does xf86-input-evdev ignore the xkb_rules option?

me. Is there an explanation, on why exactly the option to specify a different rule-file is disabled? I guess there must be a good reason, but I can't find any info on it. Best Regards Martin

Re: Window id of xterm started

On 10/02/2024 19:53, Riza Dindir wrote: Hello, I am starting xterm in my xinitrc. Is it possible to get the window id of that xterm? No-one has mentioned this solution yet, so for completeness I'll throw it in: XResQueryClientIds can be used to query the real pid of window. Unlike

[Xorg-driver-geode] release: xf86-video-geode 2.11.21

driver, instead of a hardware-specific X driver. Martin-Éric

Re: Something is keeping my X awake

I don't frequent Youtube, and I don't generally see ads. I might have Reddit open, so that could be it. Not exactly happy about this, and I will take it over to Mozilla and see what they say. At least this should be configurable. -- @martinkrafft | https://matrix.to/#/#madduck:madduck.net

Re: Something is keeping my X awake

Thanks, Carsten, for your work, and the elaborate explanation. I can somewhat understand inhibiting the screensaver when there's a video playing in the foreground, but certainly not for background activity. But this is an issue to take up with the Mozilla dudes. I don't believe that there

Re: Something is keeping my X awake

Regarding the following, written by "Vladimir Dergachev" on 2022-07-21 at 17:28 Uhr -0400: If any of such programs were terminated before they could restore the regular behaviour, the screen won't lock. Nah, the problem is different. If I run `xscreensaver-command -lock`, then the screen

Something is keeping my X awake

is someone with whom you can dare to be yourself spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

X.org 7.7, i915 chip on Thinkpad T490 no longer able to drive external display

Folks, a few days ago, my trusted Thinkpad T490 stopped being able to drive an external screen. X thinks it's there, but it doesn't wake up. I have tried all combinations of: * two different monitors * two different USB-C docks * two different USB-C cables * from the docks: DP to DVI, DP to

[Xorg-driver-geode] RFC: should this patch be merged?

at 24bpp. 1) Does this patch do what I think it does? 2) Should I merge it? Best Regards, Martin-Éric From: =?UTF-8?q?Martin-=C3=89ric=20Racine?= Date: Fri, 17 Feb 2012 17:55:27 +0200 Subject: LX: increase default BPP depth to 24-bit for generic hardware. MIME-Version: 1.0 Content-Type: text

Re: Ryzen 4500U Integrated graphics - found no way to make it work

Am Dienstag, den 24.11.2020, 10:42 -0500 schrieb Alex Deucher: > On Tue, Nov 24, 2020 at 3:53 AM Martin Wagner wrote: > > Dear mailing list, > > > > for my new job I got a just as new HP Probook X360 435 G7, > > featuring > > the AMD CPU/GPU I named above (Ry

Re: Ryzen 4500U Integrated graphics - found no way to make it work

en. No more time now to go into diagnostics, there are many more issues I have to solve before I consider this Arch install really functional. For example lightdm doesn't start, networking doesn't load either even though I installed the packages... will keep me busy -.- If anybody has any other ideas

Re: Ryzen 4500U Integrated graphics - found no way to make it work

Am Dienstag, den 24.11.2020, 17:32 +0800 schrieb Qu Wenruo: > I have a ThinkPad T14 with 4750U, with current upstream kernel (from > Arch) it works like a charm now. > > ___ > > xorg@lists.x.org: X.Org support > > Archives:

Ryzen 4500U Integrated graphics - found no way to make it work

of the black screen boots of course. Please let me know if I can provide you any further information. Thank you. Tc, Martin ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo

Re: Dummy video driver plea

On 12/05/2020 15:21, Mgr. Janusz Chmiel wrote: > Here is xorg.conf which I Am using. > > https://gist.github.com/divinity76/ce210b5dbcd9ea7d0585ac403caef577 > Which line of this file define so big resolution? In that file, all the lines starting with "Modeline" define the resolutions available

Re: 30-bit X session and programs requiring 24-bit depth

On 17/02/2020 16:40, Ilya Anfimov wrote: > On Mon, Feb 17, 2020 at 04:01:35PM +0700, Antoine Martin wrote: >> On 17/02/2020 15:51, Ilya Anfimov wrote: >>> On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote: >>>> On 14/02/2020 18:53, Marek Szuba wrote:

Re: 30-bit X session and programs requiring 24-bit depth

On 17/02/2020 15:51, Ilya Anfimov wrote: > On Sat, Feb 15, 2020 at 12:32:15AM +0700, Antoine Martin wrote: >> On 14/02/2020 18:53, Marek Szuba wrote: >>> Hello, >>> >>> I do quite a lot of photo editing on my box and with both my monitors >>> and my gr

Re: 30-bit X session and programs requiring 24-bit depth

On 14/02/2020 18:53, Marek Szuba wrote: > Hello, > > I do quite a lot of photo editing on my box and with both my monitors > and my graphics card (amdgpu) supporting 10-bit colour channels, I tend > to run X at colour depth 30. Unfortunately some software, most notably > programs using OpenGL it

Re: xserver-xorg-video-dummy driver XORG and X11vnc on Android chroot

On 30/01/2020 17:17, Mgr. Janusz Chmiel wrote: > Here you can find xorg.conf which I Am using. > > https://gist.github.com/divinity76/ce210b5dbcd9ea7d0585ac403caef577 It appears that this dummy configuration file you are using is based on the one I made for xpra. > May be, that it would be

Lightdm, X.Org X Server terminates randomly,

8c98-0fac-7317-ac5fd3c47296) @ PCI::02:00.0 ---8< GFX card is a GeForce GTX 1050 Ti, Xorg.0.log attached. Is this the right place and/or information to get an idea, what is wrong with this thing? Thanks, Martin [ 13663.456] X.Org X Server 1.18.4 Release Date: 2016-07-19 [ 13663.456

[PATCH xserver] meson: fix construction of SERVER_MISC_CONFIG_PATH

for SERVER_MISC_CONFIG_PATH. Adding the prefix is sufficient to silence the warning and add the protocol names to the extension registry at startup. Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/853 Signed-off-by: Anthony Martin --- include/meson.build | 2 +- 1 file changed, 1 insertion(+), 1

modular/release.sh issue

with this? Thanks! Martin-Éric ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

[Xorg-driver-geode] xf86-video-geode 2.11.20 released

s are welcome. Best Regards, Martin-Éric ___ Xorg-driver-geode mailing list Xorg-driver-geode@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-geode

Fault reports and bug fixes and expectations

nt to be on a plane when the pilot says "we pushed the button to lower the undercarriage - most times the wheels do come down but sometime they might now!"??? Thank you Martin Wheatley [UKAEA Logo]<https://www.gov.uk/government/organisations/uk-atomic-energy-authority> Martin

Re: YouTube Video from XDC2018 - Panfrost Lyude Paul & Alyssa Rosenzweig

allowing her to come to XDC, she definitely has a bright future in our community if she wants to. Best regards, Martin [1] https://www.freedesktop.org/wiki/CodeOfConduct/ ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.or

Re: modesetting TearFree / VSYNC aware rotation pageflipping

edesktop.org/xorg/driver/xf86-video-ati/commit/?id=798c4fd16d339b1ad5fd729cc884be084c60e38b > > Yeah, something like that would be needed. > Carsten, Would you like to add support for it on top of my branch? I am a bit swamped but I could be convinced to help you on this if needed :) Martin _

Re: X SECURITY: allowed extensions for untrusted clients

. Martin Am Sonntag, den 15.10.2017, 16:46 -0700 schrieb Keith Packard: > "Uecker, Martin" <martin.uec...@med.uni-goettingen.de> writes: > > > The question is what security risks all the different extensions > > may expose. > > For things like Render a

Re: [xserver,1/4] os: move xf86PrivsElevated here

m <mailto:nicolai.haeh...@amd.com>>" lines. You can add: Reviewed-by: Antoine Martin <anto...@nagafix.co.uk> You should probably re-send the patch series as individual emails. Cheers Antoine > > Also please note that I rebased Nicolai's original patch, > https:

[PATCH xserver v2] fixing -logfile when used with -displayfd

And below is the trivial fix for it. We only need to rename the logfile if the log filename contains the magic substitution string "%s". Signed-off-by: Antoine Martin <anto...@nagafix.co.uk> --- diff --git a/os/log.c b/os/log.c index 91e55a532..a3b28ccb4 100644 --- a/os/log.c +++ b/o

Google Summer of Code 2018

*)! Martin, on behalf of the X.Org Foundation [1] https://www.x.org/wiki/SummerOfCodeIdeas/ [2] https://developers.google.com/open-source/gsoc/timeline [3] https://www.x.org/wiki/GSoCApplication/ ___ xorg-devel@lists.x.org: X.Org development Archives

Re: [PATCH xserver 2/7] glamor: Fix loose ends in color depth 30 support.

On 20/02/18 11:06, Mario Kleiner wrote: > /* XXX handle 2 10 10 10 and 1555 formats; presumably the pixmap private > knows this? */ Maybe this comment should now be updated? Otherwise, everything looks straightforward, so for the whole series: Reviewed-by: Antoine Martin

Re: [PATCH] xfree86: add default modes for 16:9 and 16:10

On Tue, 2018-01-09 at 20:33 +0100, Martin Wilck wrote: > Improve the user experience for users with wide screens by adding > standard > 16:9 and 16:10 modes to extramodes, as suggested previously > (https://lists.x.org/archives/xorg-devel/2016-February/048866.html). > Tested suc

[PATCH] xfree86: add default modes for 16:9 and 16:10

/show_bug.cgi?id=37858. Signed-off-by: Martin Wilck <mwi...@suse.com> --- hw/xfree86/common/extramodes | 142 +++ 1 file changed, 142 insertions(+) diff --git a/hw/xfree86/common/extramodes b/hw/xfree86/common/extramodes index 450502670286..5a446938250f

Re: Merged repo for protocol headers? Why are they split?

Am 07.12.2017 17:18 schrieb "Emil Velikov" <emil.l.veli...@gmail.com>: On 6 December 2017 at 12:37, Daniel Martin <consume.no...@gmail.com> wrote: > Hi all, > > if anyone would like to have a look, I've pushed my current work on > the merged proto repo here: >

Re: Merged repo for protocol headers? Why are they split?

On 6 December 2017 at 16:23, Gioele Barabucci <gio...@svario.it> wrote: > Hi, > > 06.12.2017 13:37 Daniel Martin: >> >> PS: Just talked to Peter, he's okay with filter-branch as it gives us >> git-log without a struggle and references to other commits can

Re: Merged repo for protocol headers? Why are they split?

Hi all, if anyone would like to have a look, I've pushed my current work on the merged proto repo here: https://github.com/bartsch/xorg-proto2k/ It's generated as is with: https://github.com/bartsch/proto2k-generator/ I used git-filter-branch to: - move files to specific directories and

Re: Merged repo for protocol headers? Why are they split?

On 30 November 2017 at 14:28, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 29 November 2017 at 13:40, Daniel Martin <consume.no...@gmail.com> wrote: >> On 28 November 2017 at 16:51, Emil Velikov <emil.l.veli...@gmail.com> wrote: >>> One reasonably easy

Re: Merged repo for protocol headers? Why are they split?

On 29 November 2017 at 15:52, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Wed, 29 Nov 2017 15:44:53 +0100 > Daniel Martin <consume.no...@gmail.com> wrote: > >> On 29 November 2017 at 15:01, Daniel Stone <dan...@fooishbar.org> wrote: >> > Hi, >

Re: Merged repo for protocol headers? Why are they split?

On 29 November 2017 at 15:01, Daniel Stone <dan...@fooishbar.org> wrote: > Hi, > > On 28 November 2017 at 12:38, Daniel Martin <consume.no...@gmail.com> wrote: >> On 27 November 2017 at 23:18, Peter Hutterer <peter.hutte...@who-t.net> >> wrote: >&

Re: Merged repo for protocol headers? Why are they split?

On 28 November 2017 at 16:51, Emil Velikov wrote: > One reasonably easy way to fold the repositories [while preserving all > the history] is via git filter-branch. Yes, but, filter-branch rewrites the history too. As Peter stated earlier, this breaks commit messages

Re: Merged repo for protocol headers? Why are they split?

On 27 November 2017 at 23:18, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On Mon, Nov 27, 2017 at 09:07:12PM +0100, Daniel Martin wrote: >> On 22 November 2017 at 07:45, Adam Jackson <a...@nwnk.net> wrote: >> > On Wed, 2017-11-22 at 10:25 +1000, Peter Hutter

Re: Merged repo for protocol headers? Why are they split?

On 22 November 2017 at 07:45, Adam Jackson wrote: > On Wed, 2017-11-22 at 10:25 +1000, Peter Hutterer wrote: >> On Tue, Nov 21, 2017 at 03:28:20PM -0800, Dylan Baker wrote: >> > Your script splits each proto into a subdirectory, does it really make >> > sense to >> > do that, or

Merged repo for protocol headers? Why are they split?

Hi, I've ever wondered why are the proto headers split up into distinct repos? (It takes "ages" to just copy (install) a few files with autotools.) Dylan started to add meson support, but doing this for all protos sounds like a lot of copy'n'paste to do, lots of patches . Wouldn't it make more

[PATCH xserver 1/7] modesetting: Check for uevents on EnterVT

We have to re-evaluate the outputs (their ids) before drmmode_set_desired_modes() as it triggers drmmode_set_mode_major(). drmmode_set_mode_major() working with old ids is likely to fail and will tear down the server. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/d

[PATCH xserver 6/7] modesetting: Check for vanished outputs after updating output ids

Doing this before updating the output_ids is not a good idea as we compare the output id in the loop and the output id is unreliable. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 51 ++-- 1 file chang

[PATCH xserver 4/7] modesetting: Check mode in drmmode_set_mode_major() first

We don't do anything in drmmode_set_mode_major() without a mode. Check it at the beginning and may bail out. With that, we can remove one indention level. No functional changes. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 5/7] modesetting: Fix server crash on failing modeset

fail too. Additionally, log the crtc id if drmModeSetCrtc() fails anyway. That id plus KMS debug logs may help to solve potential other problems. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 + 1 file c

[PATCH xserver 7/7] modesetting: Squash link-status check into output re-evaluation loop

By using a helper function it looks more streamlined and we don't do to drmModeGetConnectorCurrent() in drmmode_handle_uevents() twice. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 99 +++- 1 file chang

[PATCH xserver 3/7] modesetting: Compare connector info to identify outputs

connectors is their PATH. Non-MST connectors can be identified using their type and type id. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 52 +--- 1 file changed, 46 insertions(+), 6 deletions(-) diff --gi

[PATCH xserver 2/7] modesetting: Store info to identify a connector

That is the connector_type, connector_type_id and path_blob. We'll identify a connector using this information later, as the output_id is unreliable. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 10 +++--- hw/xfree86/d

[PATCH xserver 0/7] modesetting - more stable MST hotpluging

the server down. - We have to compare the PATH if available, as the output_id is unreliable. - We have to make sure, we don't throw zero outputs to configure into drmModeSetCrtc() as this will fail and tear down the server. Thanks, Daniel Daniel Martin (7): modesetting: Check for uevents

[PATCH xserver 4/6] modesetting: Retrieve drm connector in drmmode_output_detect()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/x

[PATCH xserver 3/6] modesetting: Retrieve drm connector in drmmode_output_create_resources()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_displa

[PATCH xserver 6/6] modesetting: Get current connector infos in drmmode_output_init()

No need for modes and connector status probing here. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 5/6] modesetting: Remove mode_output member from drmmode_output

We failed to handle the mode_output member properly a few times. We can retrieve it at any time, which we do at various places anyway. Remove it. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 - hw/x

[PATCH xserver 1/6] modesetting: Save number of encoders in drmmode_output

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 13 +++-- hw/xfree86/drivers/modesetting/drmmode_display.h | 1 + 2 files changed, 8 insertions(+), 6 deletions(-) diff --gi

[PATCH xserver 0/6] modesetting - remove mode_output member

This patchset removes the mode_output member. We failed to handle it correctly in the past and most people won't notice if the do as it requires MST hotpluging. Thanks, Daniel Daniel Martin (6): modesetting: Save number of encoders in drmmode_output modesetting: Retrieve drm connector

[PATCH xserver 0/6] xdmcp, xfree86, modesetting - fixes and cleanups

- "Failed" without a new-line is not a good log message modesetting: Reset output_id if drmModeGetConnector failed - mode_output strikes again modesetting: Remove unused define DRV_ERROR modesetting: Remove #if 0 CMAP_LOAD_EVEN_IF_OFFSCREEN Thanks, Daniel Daniel Martin

[PATCH xserver 3/6] modesetting: Fix log msg if pixmap creation failed

Add a missing new-line character and make the message more verbose than "Failed". Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/dri

[PATCH xserver 1/6] os/xdmcp: Honour -once when session is dead

Terminate a dead session when -once was passed. Don't restart it. Signed-off-by: Daniel Martin <consume.no...@gmail.com> Reviewed-by: Walter Harms <wha...@bfs.de> --- os/xdmcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/os/xdmcp.c b/os/xdmcp.c index 906c9594

[PATCH xserver 2/6] xfree86: Fix set but not used warnings in lnx_platform

appear. Suggested by Emil Velikov Reviewed-by: Emil Velikov <emil.veli...@collabora.com> Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/os-support/linux/lnx_platform.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/os-s

[PATCH xserver 5/6] modesetting: Remove unused define DRV_ERROR

Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/driver.h | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/driver.h b/hw/xfree86/drivers/modesetting/driver.h index 7ea500f5c..08dc3b58a 100644 --- a/hw/xfree86/d

[PATCH xserver 4/6] modesetting: Reset output_id if drmModeGetConnector failed

If drmModeGetConnector() fails in drmmode_output_detect(), we have to reset the output_id to -1 too. Yet another spot leading to a potential NULL dereference when handling the mode_output member as output_id was != -1. Though, this case should be very hard to hit. Signed-off-by: Daniel Martin

[PATCH xserver 6/6] modesetting: Remove #if 0 CMAP_LOAD_EVEN_IF_OFFSCREEN

CMAP_LOAD_EVEN_IF_OFFSCREEN has been encapsulated since the import of xf86-video-modesetting into the tree. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --gi

Re: [PATCH xserver 00/11] modesetting: Fixes, cleanups and mode_output removal

(Sorry, for not reporting back earlier, had to do internal stuff.) Please ignore this pathset. It's superseded by distinct patchsets I'm going to send. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives:

[PATCH xserver] edid: fix off-by-one error in CEA mode numbering

The CEA extension short video descriptors contain the VIC, which starts at 1, not 0. Signed-off-by: Hector Martin <mar...@marcan.st> --- hw/xfree86/modes/xf86EdidModes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86

Re: [PATCH xserver 03/11] modesetting: Simplify mst path blob parsing

On 7 November 2017 at 14:06, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 7 November 2017 at 09:38, Daniel Martin <consume.no...@gmail.com> wrote: >> The kernel guarantees that the MST path property blob of a connector >> has a certain format and this pr

Re: [PATCH xserver 01/11] xfree86: Fix set but not used warnings in lnx_platform

On 7 November 2017 at 13:57, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 7 November 2017 at 09:38, Daniel Martin <consume.no...@gmail.com> wrote: >> ../hw/xfree86/os-support/linux/lnx_platform.c: In function ‘get_drm_info’: >> ../hw/xfree86/os-support/linux/ln

[PATCH xserver 10/11] modesetting: Remove mode_output member from drmmode_output

We failed to handle the mode_output member properly a few times. We can retrieve it at any time, which we do at various places anyway. Remove it. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 - hw/x

[PATCH xserver 11/11] modesetting: Get current connector infos in drmmode_output_init()

No need for modes and connector status probing here. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 08/11] modesetting: Retrieve drm connector in drmmode_output_create_resources()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_displa

[PATCH xserver 07/11] modesetting: Retrieve drm connector in drmmode_output_get_modes()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 28 +++- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_dis

[PATCH xserver 00/11] modesetting: Fixes, cleanups and mode_output removal

, Daniel Martin ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver 09/11] modesetting: Retrieve drm connector in drmmode_output_detect()

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/x

[PATCH xserver 03/11] modesetting: Simplify mst path blob parsing

creation function.) Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 41 +--- 1 file changed, 15 insertions(+), 26 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/d

[PATCH xserver 01/11] xfree86: Fix set but not used warnings in lnx_platform

:9: warning: variable ‘major’ set but not used [-Wunused-but-set-variable] int major, minor, fd; ^ Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/os-support/linux/lnx_platform.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --gi

[PATCH xserver 02/11] modesetting: Fix log msg if pixmap creation failed

Add a missing new-line character and make the message more verbose than "Failed". Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/dri

[PATCH xserver 05/11] modesetting: Reset output_id if drmModeGetConnector failed

If drmModeGetConnector() fails in drmmode_output_detect(), we have to reset the output_id to -1 too. Yet another spot leading to a potential NULL dereference when handling the mode_output member as output_id was != -1. Though, this case should be very hard to hit. Signed-off-by: Daniel Martin

[PATCH xserver 04/11] modesetting: Simplify output name creation

Looks much better without gotos. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 75 +++- 1 file changed, 34 insertions(+), 41 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c

[PATCH xserver 06/11] modesetting: Save number of encoders in drmmode_output

So, we don't rely on the mode_output member. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 13 +++-- hw/xfree86/drivers/modesetting/drmmode_display.h | 1 + 2 files changed, 8 insertions(+), 6 deletions(-) diff --gi

Re: [PATCH libXau 0/3] remove redundant null check on calling free()

Am 28.10.2017 19:16 schrieb "walter harms" <wha...@bfs.de>: After the last patch for libXau i checked the code with smatch and started to remove remove redundant One redundant "remove" here. ;-) All 3 patches are Reviewed-by: Daniel Marti

[PATCH xserver 1/4] modesetting: Fix potential buffer overflow

If one misconfigures a ZaphodHeads value (more than 20 characters without a delimiter), we get an overflow of our buffer. Use xstrtokenize() instead of writing/fixing our own tokenizer. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_dis

[PATCH xserver 4/4] Use ARRAY_SIZE all over the tree

Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with the ARRAY_SIZE macro from dix.h when possible. A semantic patch for coccinelle has been used first. Additionally, few macros have been inlined as they had only one or two users. Signed-off-by: Daniel Martin <consume

[PATCH xserver 3/4] test: signal-logging: Fix looping signed number tests

unsigned_tests[] was used to compute the amount of signed numbers to test. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- test/signal-logging.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/signal-logging.c b/test/signal-logging.c index 9bf39e58d..ca3

[PATCH xserver 2/4] test: input: Fix used uninitialized warning in dix_event_to_core

^~ Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- test/input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/input.c b/test/input.c index 4cd39bb48..8638f1443 100644 --- a/test/input.c +++ b/test/input.c @@ -230,7 +230,7 @@ dix_check_grab_val

[PATCH xserver 2/2] modesetting: Use helper to fetch drmModeProperty(Blob)s

Replace the various loops to lookup drmModeProperty(Blob)s by introducing helper functions. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 163 +++ 1 file changed, 77 insertions(+), 86 deletions(-) diff

[PATCH xserver 1/2] modesetting: Fix leak of tile_blob in drmmode_output_destroy

And drmModeFreePropertyBlob() can handle NULL pointers, no need to check edid_blob. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/drivers/modes

Re: [RFC xserver v4 07/14] modesetting: Use atomic modesetting to configure output/CRTCs

On 16 October 2017 at 07:02, Louis-Francis Ratté-Boulianne wrote: > To make sure we also use the same primary plane and to avoid > mixing uses of two APIs, it is better to always use the atomic > modesetting API when possible. > > Signed-off-by: Louis-Francis Ratté-Boulianne

[PATCH xserver 1/3] modesetting: Fix warning of unused variable if not GLAMOR_HAS_GBM

, where it is used. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 9afb344c8..91d850427

[PATCH xserver 3/3] modesetting: Check crtc before searching link-status property

No need to lookup the link-status property if we don't have a crtc. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/drmmode_display.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/hw/xfree86/drivers/modes

[PATCH xserver 2/3] modesetting: Remove #ifdefs XF86_PDEV_SERVER_FD

r from the external xf86-video-modesetting. Signed-off-by: Daniel Martin <consume.no...@gmail.com> --- hw/xfree86/drivers/modesetting/driver.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c ind

Re: X SECURITY: allowed extensions for untrusted clients

Hi Adam, Am Mittwoch, den 11.10.2017, 14:57 -0400 schrieb Adam Jackson: > On Fri, 2017-10-06 at 19:46 +, Uecker, Martin wrote: > > Hi, > > > > I would like to use untrusted connections for remote > > clients. Currently this does not work for me, because it is >

X SECURITY: allowed extensions for untrusted clients

, in particular the RENDER extension? Martin ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: fine grained scrolling via uinput [SOLVED - mostly]

(snip) >> And it all seems to work pretty well so far. Applications like Firefox >> can now scroll a few pixels at a time. >> >> Questions: >> 1) Anything wrong with this approach? > > well. on the face of it, it's fine. but remember, you're not triggering a > behaviour directly, you're

Re: [PATCH v2 xf86-video-dummy] Add glamor acceleration which enables native OpenGL support (v2)

eers Antoine > > Regards, > Qiang > ____ > From: Antoine Martin <anto...@nagafix.co.uk> > Sent: Saturday, August 5, 2017 8:54:11 PM > To: xorg-devel@lists.x.org; Yu, Qiang > Subject: Re: [PATCH v2 xf86-video-dummy] Add glamor accelerat

Re: [PATCH] fixing -logfile when used with -displayfd

n filenames yet. */ char pidstring[32]; snprintf(pidstring, sizeof(pidstring), "pid-%ld", Antoine > > -alan- > > On 08/27/17 10:21 PM, Antoine Martin wrote: >> Bump. This is a cosmetic bug, but it trips up many people when they >> cann

Re: [PATCH] fixing -logfile when used with -displayfd

for it) Cheers Antoine On 05/08/17 17:09, Antoine Martin wrote: > Hi, > > Trivial way to reproduce the bug: > Xorg -logfile /tmp/mylog -config /etc/xpra/xorg.conf -displayfd 2 > > The server then moans: > Failed to rename log file "/tmp/mylog" to "/tmp/mylog": No

fine grained scrolling via uinput [SOLVED - mostly]

Hi, We've got a solution to the "smooth scrolling" query from last year: https://lists.freedesktop.org/archives/xorg/2016-June/058138.html I believe that this solution is actually easier than implementing a trackstick-like device: we adjust MOUSE_WHEEL_CLICK_COUNT on a uinput device to give us 1

Re: [PATCH v2 xf86-video-dummy] Add glamor acceleration which enables native OpenGL support (v2)

uot; > And do you have this file > /dev/dri/renderD128 > and right permission to access? Yes, I chmoded it: crw-rw-rw-+ 1 root video 226, 128 Aug 2 17:04 /dev/dri/renderD128 Cheers Antoine > > Regards, > Qiang > ____ > From: Antoine

  1   2   3   4   5   6   >