Re: Dropped kdrive == fbdev regression
On Fri, 2017-03-10 at 11:25 -0500, Adam Jackson wrote:
> On Fri, 2017-03-10 at 12:52 +0000, Steven Newbury wrote:
> > Since kdrive, in particular Xfbdev has been dropped, this has left
> > a
> > hole in support for MONO (1bpp) framebuffer devices. I've been
> > using
> > Xfbdev for a picolcd mono matrix device for a few years.
> >
> > The Xorg fbdev driver only supports a minimum of 8bpp framebuffer
> > formats which wasn't a problem given the existance of Xfbdev, but
> > now
> > leaves a whole class of hardware unsupportable.
>
> Looks like this is just an oversight in the fbdev driver. Care to try
> a
> patch?
>
> diff --git a/src/fbdev.c b/src/fbdev.c
> index af1587f..0da63fb 100644
> --- a/src/fbdev.c
> +++ b/src/fbdev.c
> @@ -623,6 +623,7 @@ FBDevPreInit(ScrnInfoPtr pScrn, int flags)
> case FBDEVHW_PACKED_PIXELS:
> switch (pScrn->bitsPerPixel)
> {
> + case 1:
> case 8:
> case 16:
> case 24:
>
Thanks,
I'm sure I tried to address this before and there was something more to
it, but I'll give it a go. To be honest, I was satisfied with Xfbdev,
so I didn't try too hard to get it working.
signature.asc
Description: This is a digitally signed message part
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
Dropped kdrive == fbdev regression
Since kdrive, in particular Xfbdev has been dropped, this has left a hole in support for MONO (1bpp) framebuffer devices. I've been using Xfbdev for a picolcd mono matrix device for a few years. The Xorg fbdev driver only supports a minimum of 8bpp framebuffer formats which wasn't a problem given the existance of Xfbdev, but now leaves a whole class of hardware unsupportable. signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: modesetting and DRI2/3
On Wed, 2016-07-27 at 18:24 +0200, zahlenm...@gmx.de wrote: > Hey everyone, > I am struggling to understand how the modesetting driver and DRI play > together. > This is from Xorg.0.log: > > [ 2350.977] (II) Loading > /usr/lib/xorg/modules/drivers/modesetting_drv.so > [ 2350.977] (II) modeset(0): using drv /dev/dri/card0 > [ 2350.984] (II) glamor: OpenGL accelerated X.org driver based. > [ 2351.387] (II) modeset(0): [DRI2] DRI driver: i965 > [ 2351.387] (II) modeset(0): [DRI2] VDPAU driver: i965 > > And this is from glxinfo: > > libGL: Using DRI3 for screen 0 > > I read that modesetting uses DRI3 by default so I am a bit surprised > to > read something like "modeset(0): [DRI2]" in my logs. I also tried and > compiled xorg with the --disable-dri2 flag. In this case I get aiglx > errors that modesetting failed to initalize the DRI2 extension. > Could anyone explain this behaviour to me? > > Kind regards > ___ > xorg@lists.x.org: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: https://lists.x.org/mailman/listinfo/xorg > Your subscription address: %(user_address)s VDPAU doesn't use DRI3 as yet, AFAIK. DRI2 is still available unless it's build time disabled, even if DRI3 is default. signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH] Re: wrong display size
On Tue, 2016-06-14 at 23:46 -0400, Felix Miata wrote:
> Sebastian Gutzwiller composed on 2016-06-14 11:10 (UTC+0200):
>
> > I have a LCD display (115 mm x 86 mm) with VGA resolution (640 x
> > 480)
> > connected over LVDS with an Intel Atom N450.
>
> > After upgrading from Ubuntu 10.04 to 14.04 I only see the upper
> > left
> > detail of the whole screen (see attachment 'display_picture.jpg').
>
> > The Xorg log (see attachment 'Xubuntu.14.04.4.LTS.Xorg.0.log')
> > reported
> > a physical screen size of 270 mm x 203 mm which is pretty much the
> > size
> > of the whole screen.
>
> > Any suggestions?
>
> Something to try (I don't have any Intel Atoms to test on):
>
> 1.login on a vtty
> 2.sudo apt-get purge xserver-xorg-video-intel
> 3.reboot (or restart X xserver)
>
> Reason: sometime post-server 1.16.x. the generic modesetting driver
> was moved
> directly into the server itself. It's supposed to be competent for
> all
> non-ancient mainstream gfxchips, a substitute for chip-specific
> drivers. If
> it doesn't help, it's up to you whether to bother reinstalling the
> intel driver.
I made this patch a few years ago, still applies:
--- hw/xfree86/ddc/interpret_edid.c~2013-10-03 07:25:56.0 +0100
+++ hw/xfree86/ddc/interpret_edid.c 2013-10-03 07:48:55.168972224 +0100
@@ -144,6 +144,15 @@
xf86ForEachDetailedBlock(m, handle_detailed_hvsize, );
+if ((p.real_hsize != m->features.hsize ) ||
+(p.real_vsize != m->features.vsize)) {
+xf86Msg(X_INFO, "Inconsistency in detected Display Size:\n");
+xf86Msg(X_INFO, "Monitor features physical dimensions %dx%d mm\n",
+m->features.hsize, m->features.vsize);
+xf86Msg(X_INFO, "Detailed timings physical dimensions %dx%d mm\n",
+p.real_hsize, p.real_vsize);
+}
+
if (!p.real_hsize || !p.real_vsize) {
m->features.hsize = m->features.vsize = 0;
}
--- hw/xfree86/modes/xf86Crtc.c.orig2013-11-01 16:59:03.904169898 +
+++ hw/xfree86/modes/xf86Crtc.c 2013-11-01 17:06:28.387359579 +
@@ -3052,8 +3052,15 @@
(det_mon->section.d_timings.v_size * 12)) &&
((det_mon->section.d_timings.v_size * 5) <
(det_mon->section.d_timings.h_size * 12))) {
-p->output->mm_width = det_mon->section.d_timings.h_size;
-p->output->mm_height = det_mon->section.d_timings.v_size;
+if (!(p->output->conf_monitor &&
+(p->output->conf_monitor->mon_width > 0 &&
+p->output->conf_monitor->mon_height > 0))) {
+/*
+ * Do not update size if user configured DisplaySize
+ */
+p->output->mm_width = det_mon->section.d_timings.h_size;
+p->output->mm_height = det_mon->section.d_timings.v_size;
+}
p->ret = TRUE;
} else
xf86DrvMsg(p->output->scrn->scrnIndex, X_WARNING,
@@ -3109,6 +3116,15 @@
xf86OutputSetEDIDProperty(output, edid_mon ? edid_mon->rawData : NULL,
size);
#endif
+if (output->conf_monitor &&
+(output->conf_monitor->mon_width > 0 &&
+output->conf_monitor->mon_height > 0)) {
+/*
+ * Prefer user configured DisplaySize
+ */
+output->mm_width = output->conf_monitor->mon_width;
+output->mm_height = output->conf_monitor->mon_height;
+}
if (edid_mon) {
signature.asc
Description: This is a digitally signed message part
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
kdrive udev/seat support
I'm adding udev/seat support to kdrive* in order to support running Xfbdev on a picolcdfb device (USB mono LCD + keys) as an auxiliary video display on which I'll run a graphical system monitor like Conky. Right now I have basic -seat support working, when !seat0 vt switching is disabled and it uses the appropriate fb device according to udev. This is enough to get it working for me since I can now just start Xfbdev with the appropriate evdev for input, as I've not yet implemented seat based input device configuration. Is there any interest in getting this upstream? Shall I post the work done so far, or get the input device configuration finished first? *I would have just used Xorg, but the fbdev driver doesn't support MONO01 visuals, it seemed easier to add the missing -seat support to kdrive. signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: Text Input Box with Xlib
On Sun, 2013-02-03 at 19:35 -0200, Gabriel Duarte wrote: Hello! No, you didn't get the ideia. I do no want to use a toolkit, I'm writing a toolkit. It's an exercise and for fun, not something professional like GTK+, Qt or TK. I have already used GTK+ and Qt, even FLTK for my projects, so using them is not the big deal. I just asked here for someone who had some experience building this kind of stuff and because I'm not so experienced to Xlib. Wouldn't it be more beneficial for you to work with XCB? http://en.wikipedia.org/wiki/Xcb ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: hald
On Thu, 2013-01-31 at 09:01 -0800, Etienne Robillard wrote: Thanks. But i didn't use --disable-config-hal... It was set to the default (auto). For that reason I was hoping not to have to mess with hald to make the server running again. I guess i'll have to explicitely attempt to use the --disable-config-hal flag next time I want to try a build. I'm pretty sure HAL is disabled by configure if udev support is detected. Input hotplug requires one of the other, udev is preferred. hal/dbus is such a mess anyway that i'm quite happy to learn its being deprecated by udev. :) Cheers, Etienne On Thu, 31 Jan 2013 08:51:46 +1000 Peter Hutterer peter.hutte...@who-t.net wrote: HAL hasn't been required on linux since server 1.8 where we switched to udev. If you disable hal you'll need to install the udev devel package to make sure you have at least one config backend. right now, I suspect that you disable HAL, udev isn't enabled so the server simply doesn't detect your input devices. Cheers, Peter ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: st...@snewbury.org.uk ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: multiseat dfedora17
On Thu, 7 Jun 2012, 17:53:54 BST, masoud javadieh javadieh@gmail.com wrote: I could use fedora 14 for two seats using one Intel onboard graphic card and one pci Nvidia card. Now under fedora 17 only one of them works and the other freezes with a white squre on let top of monintor. how can I set Graphic cards too have multiseats? systemd automatic multi-seat currently only uses fbdev, so you need to have either a KMS or fb driver for your Nvidia. As it happens, I've actually patched it to use the accelerated KMS drivers, I'll make the patch available once I've cleaned it up a little. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
