each extension. Hopefully I won't run out of
ids...
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
A: Because it messes up the order in which people normally read text.
Q
them needs
to use the sed g flag to replace all instances, not just the first.
Committed, thanks.
Btw, would you like commit rights? I'd say you have enough street cred
for that not to be an issue. :)
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer
(request == MappingKeyboard ||
+request == MappingModifier))
XkbApplyMappingChange(dev, request, firstKeyCode, count, client);
#endif
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
,
+ valuators);
+numEvents += numReleaseEvents;
+events += numReleaseEvents;
}
}
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http
into the
noXkbExtension block too.
Bug 21455.
Want me to do the same for this:
http://lists.x.org/archives/xorg-devel/2009-April/000744.html
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http
input layer for some time now.
Do you have any ideas?
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description: PGP signature
On Thu, 30 Apr 2009 12:25:50 +1000
Peter Hutterer peter.hutte...@who-t.net wrote:
On Tue, Apr 28, 2009 at 04:07:37PM +0200, Pierre Ossman wrote:
The reason this happens is how Xorg handles the mapping between the
multiple keyboards internally and the single keyboard exposed via X11
On Fri, 1 May 2009 15:40:50 +1000
Peter Hutterer peter.hutte...@who-t.net wrote:
On Thu, Apr 30, 2009 at 09:14:43AM +0200, Pierre Ossman wrote:
In which case I'd consider the mechanism for adding new keyboards
broken. If the idea is that the modifier mapping should be global
like a reasonable
way to solve this. I thought about changing the BlockHandlerProc
definition, but it is exposed in application headers so it didn't seem
safe to touch.
PS. Please cc me on any replies, and allow for some delay in responses
on account of holidays. :)
Rgds
--
Pierre Ossman
On Fri, 23 Jan 2015 07:35:04 -0800,
Keith Packard wrote:
Pierre Ossman oss...@cendio.se writes:
On Thu, 25 Dec 2014 13:55:13 -0800,
Keith Packard wrote:
Pierre Ossman oss...@cendio.se writes:
Please see the attached patch and see if this seems like a reasonable
way to solve
On Thu, 25 Dec 2014 13:55:13 -0800,
Keith Packard wrote:
Pierre Ossman oss...@cendio.se writes:
Please see the attached patch and see if this seems like a reasonable
way to solve this. I thought about changing the BlockHandlerProc
definition, but it is exposed in application headers so
On Mon, 26 Jan 2015 10:25:48 -0800
Keith Packard <kei...@keithp.com> wrote:
> Pierre Ossman <oss...@cendio.se> writes:
>
> > Great. Can it get queued up for the next releases in that case?
>
> It's in my list, yes.
>
Ping. Still in the list? :)
Rgds
--
On 16/01/17 21:36, Adam Jackson wrote:
On Fri, 2017-01-13 at 15:07 +0100, Pierre Ossman wrote:
I'll answer myself here...
This seems to be a CPU cache issue. Below this limit I see:
4,469,985 cache-misses:u#0.336 % of all cache refs
35,279,259,258
()
returns 0, then flush() will simply retry again (and again and again),
if I read the code correctly), so it will *busy* wait until all data
is written.
I'll have a look. It may simply be that flush() is defined as always
blocking. I'll check who calls it.
Regards
--
Pierre Ossman
_LogParameter param, int value);
extern _X_EXPORT void
LogVWrite(int verb, const char *f, va_list args)
_X_ATTRIBUTE_PRINTF(2, 0);
Is this a fix that's meant to go upstream at some point?
Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
T
This was causing crashes in TigerVNC with Chrome/Chromium.
Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköpinghttps://facebook.com/ThinLinc
Phone: +46-13-214600https
Sprites (and hence cursors) can be shared between multiple devices.
However the animation code was not prepared for this and could wind
up in a case where it would continue to animate a free:d cursor.
---
include/inputstr.h | 14 -
render/animcur.c | 85
, and only things drivers shouldn't access anyway.
So it's only an issue if they depend on the size of those structs.
Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköpinghttps
+if (!activeDevice)
+activeDevice = TRUE;
why the check here ? just set.
Historical reasons I guess. This is not code I changed, just re-indented.
Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen
On 12/01/17 13:53, Pierre Ossman wrote:
>
> For small updates I see performance growing logarithmically, measured in
> pixels/second. At around 500k pixels it starts leveling off at ~1.5
> Gpixels/second. After that the performance starts dropping linearly as
> the update grow
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköpinghttps://facebook.com/ThinLinc
Phone: +46-13-214600https://plus.google.com/+CendioThinLinc
A: Because it messes up the order
On 05/01/17 17:44, ipilc...@redhat.com wrote:
On Wednesday, October 5, 2016 at 4:13:48 AM UTC-5, Pierre Ossman wrote:
Alright. I'll have a look at doing the finishing touches. Thanks for the
patch. :)
FYI, there seems to be an issue with either the patch or v1.19 itself.
https
On 09/01/17 20:15, Hans de Goede wrote:
Yes I agree that would be better, Pierre, can you take care
of merging Alan's improved version ?
All done and available on master now. Thanks for fixing this.
Regards
--
Pierre Ossman Software Development
Cendio AB https
by accessing the same
memory. But apparently¹, gbm_bo_map() isn't guaranteed to actually map
memory.
¹
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/945#note_1483370
Regards,
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8
Regards
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköpinghttps://facebook.com/ThinLinc
Phone: +46-13-214600
A: Because it messes up the order in which people normally read te
,
--
Pierre Ossman Software Development
Cendio AB https://cendio.com
Teknikringen 8 https://twitter.com/ThinLinc
583 30 Linköpinghttps://facebook.com/ThinLinc
Phone: +46-13-214600
A: Because it messes up the order in which people normally read text.
Q: Why
26 matches
Mail list logo
