he FBO cache *iff* the driver
supports this extension?
Max
___
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
h look at my old
series.
There was a lot of broken, as well as dead (!) code that I had to fix
to make this workable on VC4. If we reintroduce a FBO cache, at least
let's do it right this time.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: ht
dering for now, at
least as the default setting of an xorg.conf option...
Max
___
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
- and making sure that everything
behaves like mi?
I'd even leave the existing GL lines code intact, as it's really cool to
have. But disabled by default, so users get the precise experience first,
and can decide to switch to a quick-but-imprecise OpenGL based experience
if they wish to d
On 02/13/2017 11:53 PM, Keith Packard wrote:
> afaict, GL suggests 'not
> last' as the only option. It sounds like some drivers are doing both
> 'not last' and 'not first' though?
In the case that I reproduced, the 'not first' only happens occasionally, but
reproducib
https://bugs.freedesktop.org/show_bug.cgi?id=99708 - should
we fall back to mi until we have a better approximation in GLAMOR?
It's sad to see acceleration go, but currently it seems to create a lot of
confusion. And raw X11 ops are barely used (if at all) in average modern
On 02/07/2017 09:06 PM, Keith Packard wrote:
> Max Staudt <msta...@suse.de> writes:
>
>> OpenGL implementations are allowed to be imprecise in drawing line caps.
>> This patch expands on the original workaround in dc9fa908.
>
> Yeah, finding a way to work around GL
OpenGL implementations are allowed to be imprecise in drawing line caps.
This patch expands on the original workaround in dc9fa908.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99705
Signed-off-by: Max Staudt <msta...@suse.de>
---
glamor/glamor_lines.c | 21 +
On 07/18/2016 09:24 PM, Adam Jackson wrote:
> On Mon, 2016-07-18 at 20:38 +0200, Max Staudt wrote:
>
>> What happened to this patch? I cannot find any discussion on it on
>> [xorg-devel].
>
> You have correctly identified what happened to this patch: it was sent,
&
On 07/18/2016 07:10 PM, Eric Anholt wrote:
> Adam Jackson <a...@nwnk.net> writes:
>
>> On Mon, 2016-07-18 at 14:36 +0200, Max Staudt wrote:
>>> Shall I send a patch to delete GLAMOR's BO cache instead?
>>
>> Yes please, that would be lovely.
>
> http
leting it, too.
Shall I send a patch to delete GLAMOR's BO cache instead?
Comments?
Max
___
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
Deduplify code and make sure glamor_priv->tick++ actually happens.
This ensures that GLAMOR's BO cache is expunged every now and then
even if it's not full yet.
Note: glamor_block_handler() contains both lines removed in this
change, so the old functionality persists.
Signed-off-by: Max Sta
GL_APPLE_object_purgeable, as
implemented by the i915/i965 driver.
Signed-off-by: Max Staudt <msta...@suse.de>
---
glamor/glamor_fbo.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index c
dragging may allocate megabytes of memory.
Signed-off-by: Max Staudt <msta...@suse.de>
---
glamor/glamor_fbo.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index f80c20d..b27f652 100644
--- a/glamor/glamor_fbo.c
+++ b/
?
Thanks,
Max
___
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
Signed-off-by: Max Staudt <msta...@suse.de>
---
glamor/glamor_fbo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index b27f652..733c3a8 100644
--- a/glamor/glamor_fbo.c
+++ b/glamor/glamor_fbo.c
@@ -164,7
:
From: Reinhard Max <m...@suse.de>
For IPv6 add a link local addresses to the end of the list
passed to the XDMCP servers. Reason: for link local addresses
the XDMCP server would need to either know the interface thru a
scope identifier or try all available interfaces. If they
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
hw/xfree86/common/compiler.h|5 -
hw/xfree86/os-support/linux/lnx_video.c |3 ++-
include/servermd.h | 14 ++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86
Disables the button click generation (EvdevWheelEmuInertia) and
generates scroll valuator events directly.
Signed-off-by: Max Schwarz max.schw...@online.de
---
I tried to support turning wheel emulation on/off at runtime.
This involves calling InitValuatorClassDeviceStruct() again
to add the new
Hi Peter,
On Thu, 2013-07-04 at 15:51 +1000, Peter Hutterer wrote:
Hi Max,
had a short play with it and it worked as expected. one thing I do have to
caution you for is that the xinput commandline is not a stable API and may
change at any time - breaking the script. You're much better off
itself.)
It works by emitting xinput commands. It is written for Python 2.7 and
wxPython 2.8. It seems to work pretty well, although there may still be
bugs. A more detailed README, source code, a screenshot are available on
the GitHub page for the project:
https://github.com/Max-E/xinput-ui
Problem:
I have dual head videocard nvidia 6200 (agp) with VGA and DVI.
Resolution of monitor is 1600x1200 on VGA head. But maximum resolution
of monitor on DVI head (through DVI to VGA) is only 640x480. How to set
bigger resolution?
P.S. Sorry for my english.
My environment:
Videocard:
# lspci
is used everywhere.
This wouldn't be a problem if we exclusively used SetBit/BitIsOn everywhere.
But we get the bitmask from the kernel, which uses longs and uses correct byte
order...
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
smooth-scrolling on wheel emulation patch.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
src/evdev.c | 76
as inline, that would need
to be changed prior to merging.
I'll try to send in a patch for byte-bitmasks sometime this week, so we can
look how that looks.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
smooth-scrolling on wheel emulation patch.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
sorry, forgot to actually make EvdevBitIsSet/EvdevSetBit inline
We can't use BitIsSet/SetBit from the server (inputstr.h) since they
operate on byte arrays. EvdevSetBit is added in preparation for the
smooth-scrolling on wheel emulation patch.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
make that static inline -.-
src/evdev.c | 76
Why not have EvdevBitIsSet and EvdevSetBit use BitIsSet/SetBit with
endianness-fu?
What would you gain from that? I think my implementation is simple and
straight, endianness-fu isn't going to make it nicer...
Max
___
xorg-devel@lists.x.org: X.Org
that this bit looks bad, maybe we could rename TestBit to
evdev_TestBit to match evdev_SetBit?
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
a REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Resend, my E-Mail client ate the patch...
src/emuWheel.c | 19 ++-
src/evdev.c| 34 +++---
src/evdev.h|4 +++-
3 files changed, 48 insertions(+), 9
This bug led to inverted scrolling axes with legacy drivers that
do not support smooth scrolling classes.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Applies on Peter's next branch.
dix/getevents.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/dix
scrolling up or left → button 4 or 6 */
Since incr 0 and delta 0, we get button 5.
So either that condition needs to be changed, or the conversion in
GetPointerEvents() needs to be flipped.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http
a REL_DIAL axis present in hardware.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Hi Peter,
here's a tentative patch for evdev for smooth wheel emulation. It applies on
your smooth-scrolling branch.
Note: Without this patch (i.e. using the old button interface) wheel emulation
direction
an idea about how to
proceed with GTK as well.
Best regards,
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
(1UL 32) evaluates to 0 (at least here), so do the
fraction calculation in two steps as in libXi. Fractions on xXIRawEvent
were not multiplied at all, which also gave 0 as result.
Signed-off-by: Max Schwarz m...@x-quadraht.de
---
Hi,
I noticed a problem (see patch) with Daniel Stone's patch
woha, I didn't notice someone else stepped up and did it even better
(XIScrollClass co by Peter). I'll look into that now, sorry for the noise.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info
to call
xf86SetValuatorAxisNoIntegration() after xf86InitValuatorAxisStruct() again...
I would propose specific methods for changing the resolution, axes ranges,
etc., and one final call to send out events.
Max
___
xorg-devel@lists.x.org: X.Org
(DeviceIntPtr dev, int axnum, int min, int max,
int current)?
This method could directly send out the DeviceChangedEvent. Would that still
be a layer violation?
I'll add that to my patch in the next days.
But in general, I don't mind being pestered if something usable seems
likely to emerge from
pscrolltest.c).
Are the drivers allowed to access the valuator structure
(e.g. dev-valuator-axis[0].resolution = XY) or should I implement wrapper
functions in the server to do that?
Sorry for asking many questions, are there any specs/guidelines I could use
instead of pestering you all?
Max
) if someone wants to
change the evdev wheel resolution. I think the right solution would be to emit
a XI event telling the client that the device has changed.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
?
Another question: The output from the synaptics driver fluctuates quite a bit
when one tries to stay at the current scrolling position. Do you think
filtering would need to be implemented in the synaptics driver or globally in
the server?
Thanks,
Max
people can tune
these settings.
Okay, I will implement it in synaptics, we'll see if it is needed by other
drivers.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman
the no_integration
flag, which is not really the same).
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
-Original Message-
From: Mikhail Gusarov [mailto:dotted...@dottedmag.net]
Sent: 2010年6月7日 14:55
To: Yu, Max A
Cc: xorg-devel@lists.x.org
Subject: Re: [PATCH] xephyr: Re-enabled Xnest fix for focus in + modifier bug.
Twas brillig at 10:24:26 07.06.2010 UTC+08 when max.a
Signed-off-by: Xiaoyang Yu (Max) max.a...@intel.com
Reviewed-by: Mikhail Gusarov dotted...@dottedmag.net
---
hw/kdrive/ephyr/ephyr.c | 107 ---
1 files changed, 45 insertions(+), 62 deletions(-)
diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr
be better to implement this in
the input drivers or in the server itself?
I'll experiment with cutting the events below a certain threshold to
reduce/block the noise.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
Hi,
results!
I'm finally content with how the code looks and feels :-)
Comparison:
before: http://c-palb.de/~max/before.ogg
after: http://c-palb.de/~max/after.ogg
The videos don't do the change justice, it feels _much_ more natural.
I had to patch the respective input drivers, the server
-Original Message-
From: Mikhail Gusarov [mailto:dotted...@dottedmag.net]
Sent: 2010年6月4日 17:32
To: Yu, Max A
Cc: xorg-devel@lists.x.org
Subject: Re: [PATCH] xephyr: Re-enabled Xnest fix for focus in + modifier bug.
Twas brillig at 17:26:46 04.06.2010 UTC+08 when max.a
f9da417163b6b2d6234d2542c1f375e33db7159a. This patch
is to re-enable it based on current Xnest code.
From 8ae0e6bf48b731faf2d32a92837335a6b607723f Mon Sep 17 00:00:00 2001
From: Xiaoyang Yu (Max) max.a...@intel.com
Date: Fri, 4 Jun 2010 12:04:40 +0800
Subject: [PATCH] Re-enabled Xnest fix for focus
/show_bug.cgi?id=3030 ). The patch has been
disabled by commit f9da417163b6b2d6234d2542c1f375e33db7159a. This patch
is to re-enable it based on current Xnest code.
From 1f66f708da4fa3cd7b379d33b7ed227fb75750d1 Mon Sep 17 00:00:00 2001
From: Xiaoyang Yu (Max) max.a...@intel.com
Date: Fri, 4 Jun 2010 17
scrolling, but perhaps it can be avoided.
Anyway, my code is available for anyone interested at
http://github.com/x-quadraht/pscroll
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org
on the client side? Overflow detection
is possible, but not very nice as the values are doubles...
Clearly, the right way would be to report relative events.
I will start looking into Xorg where this addition of relative events takes
place.
Max
___
xorg-devel
the relative motions?
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
. In that way the value is independant of
screen resolution and font size, and toolkits can then decide how many pixels
to scroll depending on those values.
Max
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg
it is intended to be in units/m
(XI2proto.h:184), while we want units/scrollclick or something like that.
If we can use that field then it's not much more work. Toolkits can recognize
the right valuator through the label and get the associated resolution, all
via XI2.
Max
such a feature.
Thank you very much for the suggestion. I had thought of acceleration before,
but as you said, I first have to get basic event reporting working.
ptrveloc.h is a very good hint though, X.org is really a place to get lost in
:-)
Max
___
xorg
xf86PostMotionEvent or create a new
xf86PostScrollEvent?
2) I really would like to extend the keyButtonPointer xEvent in Xproto.h to
report the relative scrolling motions, but would that break compability?
Should I use GenericEvent?
Thank you,
Max Schwarz
This would break compability. Old software just expecting a few button ticks
would suddenly scroll wildly.
2) Provide additional axis events with true resolution
I realize that the GUI frameworks would also need work to make them use the
new interface.
Thank you,
Max Schwarz
Confirmed: the radeon module was already in the system together with radeonhd;
so I simply changed the Driver string in the xorg.conf and now everything works
well.
Thank you.
Max
- Original Message
From: Vidar Haugsvær vidar.haugs...@gmail.com
To: xorg-driver-ati@lists.x.org
Sent
Yeah, I see.
I was misleaded by someone who wrote that OpenSuse 11.2 installs radeon by
default.
I will have to install the radeon driver instead (even if actually I don't have
the slightest idea how to do that: I need to study :) )
Thank you,
Max
- Original Message
From: Michel
in the
interface (menus, toolbar);
I'm available for some test, with your help, to understand if there is some way
to improve situation.
For example, adding some option to the Device section of Xorg.conf that I
recreated with Sax2.
Thank you for any suggestion
Max
Hi -
I am running a recently installed FreeBSD 7.0 system with the default xorg:
X.Org X Server 1.4.0
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 7.0-RELEASE i386
Current Operating System: FreeBSD ironteeth.home 7.0-RELEASE FreeBSD
7.0-RELEASE
62 matches
Mail list logo
