Gene Heskett composed on 2016-03-25 20:52 (UTC-0400):
Felix Miata wrote:
...
Looks like a 3-wire cord to me, and $14.99 in the current sale
catalog.
By golly gee, I do believe you are correct, so they've "fixed" that
problem. And 15 bucks is less than I paid for one 25 years ago when smd
On Friday 25 March 2016 17:47:48 Felix Miata wrote:
> Gene Heskett composed on 2016-03-25 15:55 (UTC-0400):
> >> http://www.mcmelectronics.com/product/TENMA-21-8230-/21-8230
> >> wouldn't do it?
> >
> > Possibly, that looks a lot like the one I used (handles are
> > identical) back in the later
Gene Heskett composed on 2016-03-25 15:55 (UTC-0400):
http://www.mcmelectronics.com/product/TENMA-21-8230-/21-8230 wouldn't
do it?
Possibly, that looks a lot like the one I used (handles are identical)
back in the later 90's but with different tips.
Looks like a 3-wire cord to me, and
On 2016-03-24 19:49, Jasper St. Pierre wrote:
I think this should be done at the application level. If an
application is running, it has many other ways to fingerprint your
computer, including listing the files in your homedir, checking cpuid,
MAC address, etc.
Many solutions like
Andy Furniss wrote:
Michel Dänzer wrote:
From: Michel Dänzer
This reverts commit cd94248ffa7d8fe0b57476f79e7e860dee66d1b0.
It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU
code doesn't support DRI3 yet. We can consider re-enabling this once
Michel Dänzer wrote:
From: Michel Dänzer
This reverts commit cd94248ffa7d8fe0b57476f79e7e860dee66d1b0.
It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU
code doesn't support DRI3 yet. We can consider re-enabling this once
there is a Mesa release
Hi,
On Fri, Mar 25, 2016 at 11:03:36AM +0100, martin f krafft wrote:
> Hi Andreas,
>
> Thank you for taking your time to reply. I've since followed up
> having found the problem, and I think it must be one of the DP ports
> on the graphics card.
Ooook.
> Now, you write:
>
> > Perhaps
Hi Andreas,
Thank you for taking your time to reply. I've since followed up
having found the problem, and I think it must be one of the DP ports
on the graphics card.
Now, you write:
> Perhaps unthinkable, but the connectors of the card might be
> implemented / wired up asymmetrically, e.g. due
From: Michel Dänzer
No longer needed now that xf86CursorResetCursor is getting called for
each CRTC configuration change.
Signed-off-by: Michel Dänzer
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 5 ---
hw/xfree86/modes/xf86Crtc.h
From: Michel Dänzer
Even if the driver is handling the transform, we still need to transform
the cursor position for clipping, otherwise we may hide the HW cursor
when the cursor is actually inside the area covered by the CRTC.
v2: Use crtc_x/y local variables for
From: Michel Dänzer
The driver can now specify exactly which aspects of the transform it
wants to handle via XF86DriverTransform* flags.
Since the driver can now choose whether it wants to receive transformed
or untransformed cursor coordinates,
From: Michel Dänzer
Consolidate to a single if/else statement and eliminate the redundant
local variable in_range and assignments to x/y.
Signed-off-by: Michel Dänzer
---
hw/xfree86/modes/xf86Cursors.c | 16
1 file changed, 4
Dnia piątek, 25 marca 2016 10:22:41 Andreas Mohr pisze:
> On Thu, Mar 24, 2016 at 11:18:01AM +, xorg-requ...@lists.x.org wrote:
> > Date: Thu, 24 Mar 2016 12:12:34 +0100
> > From: martin f krafft
> > There is something very weird going on, which you may witness in the
> >
On Thu, Mar 24, 2016 at 11:18:01AM +, xorg-requ...@lists.x.org wrote:
> Date: Thu, 24 Mar 2016 12:12:34 +0100
> From: martin f krafft
> There is something very weird going on, which you may witness in the
> video downloadable here:
>
14 matches
Mail list logo