distributions released over 10 years ago. One of the nice
things about git is that it makes maintaining local patchsets easy. If
you'd like to take on the responsibility of maintaining a light fork of
Xorg with libc5 support then I think people would be absolutely fine
with that.
--
Matthew Garrett
try this patch?
--- xstart.bak 2011-02-24 10:12:52.135903210 -0500
+++ xstart 2011-02-24 10:12:58.321043134 -0500
@@ -1,3 +1 @@
-Xorg -configure //1st flickering here
-cp -rf /root/xorg.conf.new /etc/X11/xorg.conf
startx //2nd flickering here
--
Matthew Garrett | mj...@srcf.ucam.org
:
patch xstart.diff
Now do bash xstart and see if X starts with only one flicker.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org
On Thu, Feb 24, 2011 at 09:41:15AM -0800, lfs lfs wrote:
hi, Matthew Garrett
But, I never received any patch or link to that.
Did you attach it in email
to add support for requesting the EDID via ACPI.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your
seem like a great plan (compare the code quality of nouveau, intel and
radeon to that of some of the out of tree drivers, for instance)
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg@lists.freedesktop.org: X.Org support
Archives: http
involved in the kernel.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch
; when I switched to terminal
mode(on linux alt-ctrl-1), it is 55w.
X knows how to program power-saving features in your graphics card. If
you're using a VGA text console, the kernel doesn't.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
and
that's a *good* thing, but it does mean that we need to revisit the 255
keycode issue.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
by linus or the other main kernel devs.
bummer, really.
It doesn't matter whether you're using tuxonice or whatever - there's
simply no infrastructure in the kernel for reinitialising multiple video
cards until you move to KMS-based drivers.
--
Matthew Garrett | mj...@srcf.ucam.org
as the kernel keycode is KEY_BATTERY, the X keycode will
depend only on whether kbd or evdev is in use.
And now we've come to the main question in my first mail: how can i
detect whether the X server uses the evdev or kbd driver?
Like I said, don't. Add the kbd keycodes to the pc105 keymap.
--
Matthew
.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
. These translations are different
when the evdev input driver is used by the X server instead of the kbd
driver.
This sounds like the wrong way to do it. Why not just ensure that the
keymap contains the correct keycode-keysym mappings in the first place?
--
Matthew Garrett | mj...@srcf.ucam.org
On Fri, Feb 20, 2009 at 09:34:38AM +0800, Sheldon Zhao wrote:
So, vbetool saves and restores the video card state, and the Xorg don't
even know a S3/S4 happen?
Either vbetool or the kernel graphics drivers. X only sees a VT switch.
--
Matthew Garrett | mj...@srcf.ucam.org
usefully respond to directly.
They're all passed to userspace which will take appropriate actions.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
/eventX)
thanks
Why do you want to do this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
vbestate restore
in text mode after resuming does the trick for me.
That's a common workaround.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
that device, but not
doing anything to prevent them being delivered through the console
device. THe kernel pays no attention to any information from hal.
--
Matthew Garrett | mj...@srcf.ucam.org
___
xorg mailing list
xorg@lists.freedesktop.org
http
a long time ago, which now
is on http://bugzilla.kernel.org/show_bug.cgi?id=6001
No, _DOS has nothing to do with the behaviour on resume.
--
Matthew Garrett | [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org
identifier?
/dev/input/by-id/ , though most input devices don't have unique
identifiers.
--
Matthew Garrett | [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
of
the X side of things.
--
Matthew Garrett | [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
if there is a known problem in 2.4.1.
Did Ubuntu 8.04 use the hardware overlay by default? Does 8.10 use the
textured one?
--
Matthew Garrett | [EMAIL PROTECTED]
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Tue, Oct 28, 2008 at 09:50:56AM -0400, Drew Ogle wrote:
xinput list doesn't show the device, so I can't use evtest.
evtest is run against the /dev/input device node, not against an xinput
device.
--
Matthew Garrett | [EMAIL PROTECTED]
___
xorg
itself, but I'm concerned about how successfully it would be deployed in
that situation.
I think shipping it with vmmouse ought to work - distributions are going
to have to upgrade some component in any case.
--
Matthew Garrett | [EMAIL PROTECTED
On Mon, Oct 27, 2008 at 11:50:42AM +, Matthew Garrett wrote:
Hmm. The fdi seemed to be missing?
No it wasn't, I'm just blind. I think a better way of doing this would
be to make the callout conditional on there being a PCI device with the
vmware subsystem. Probing for a vmware mouse
On Mon, Oct 27, 2008 at 08:35:39AM -0700, Philip Langdale wrote:
Matthew Garrett wrote:
No it wasn't, I'm just blind. I think a better way of doing this would
be to make the callout conditional on there being a PCI device with the
vmware subsystem. Probing for a vmware mouse on every
would break existing use cases. It sounds like changing
usbtouchscreen to send both events (at least optionally) would be more
reasonable, but you'd probably want to discuss that with upstream.
--
Matthew Garrett | [EMAIL PROTECTED]
___
xorg mailing
27 matches
Mail list logo
