Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-10 Thread Emil Velikov
On 10 March 2017 at 16:32, Adam Jackson  wrote:
> On Wed, 2017-03-08 at 17:44 +, Jon Turney wrote:
>> On 06/03/2017 22:20, Adam Jackson wrote:
>> > On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:
>> >
>> > > Unfortunately, one of the possible definitions of _X_EXPORT in
>> > > Xfuncproto.h is empty, in which case, this leaves us with nothing in
>> > > sdksyms.c
>> >
>> > Though this be true, I'm not sure how it can matter. We only build
>> > xfree86 on systems where _X_EXPORT expands to something non-empty. And
>>
>> It has been possible to build an xfree86 server for Cygwin since this
>> [1] patchset.
>>
>> This might even turn out to be useful, if the idea of removing Xephyr,
>> Xnest and Xvfb servers [2], to be replaced by invoking the Xorg server
>> with the xf86-video-dummy or xf86-video-nested drivers, ever happens.
>
> I neither expect nor want this to happen. dummy might have some minor
> utility, but the nested driver I think is a mistake, and I would not
> consider its availability as a reason to drop Xnest or Xephyr.
>
Pardon the silly question, but going through the discussions did now help much.
Do we have a list of features/bugs for/against each suggestion ?

I mean if there is somethings clearly defined, divide and conquer is the way.
Atm everything seems quite magical, unless one has extensive prior
experience with the DDXen and respective drivers.

-Emil
___
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

maybe xorg server?: gnome is not starting without a screen connected?

2017-03-10 Thread Simon Eigeldinger

Hi all,

I am a blind person from austria.
I am using the computer often without a screen.
I figured out on many distros there are issues with the desktop without 
a screen.

Seems the desktop isn't coming up when no screen is connected?
I read in the arch wiki that this is caused by the screen auto config 
function of the server.

can that be worked around?
I wanted to install a system on a machine but the live dvd seems not to 
come up because of this.
Is there something i can specify at boot? for example some parameters i 
can enter at the boot menu?



For people using no screen this is pretty frustrating.

greetings and thanks for helping,
Simon

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
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: Dropped kdrive == fbdev regression

2017-03-10 Thread Steven Newbury
On Fri, 2017-03-10 at 11:25 -0500, Adam Jackson wrote:
> On Fri, 2017-03-10 at 12:52 +, 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

Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-10 Thread Adam Jackson
On Wed, 2017-03-08 at 17:44 +, Jon Turney wrote:
> On 06/03/2017 22:20, Adam Jackson wrote:
> > On Mon, 2017-03-06 at 18:23 +, Jon Turney wrote:
> > 
> > > Unfortunately, one of the possible definitions of _X_EXPORT in
> > > Xfuncproto.h is empty, in which case, this leaves us with nothing in
> > > sdksyms.c
> > 
> > Though this be true, I'm not sure how it can matter. We only build
> > xfree86 on systems where _X_EXPORT expands to something non-empty. And
> 
> It has been possible to build an xfree86 server for Cygwin since this 
> [1] patchset.
> 
> This might even turn out to be useful, if the idea of removing Xephyr, 
> Xnest and Xvfb servers [2], to be replaced by invoking the Xorg server 
> with the xf86-video-dummy or xf86-video-nested drivers, ever happens.

I neither expect nor want this to happen. dummy might have some minor
utility, but the nested driver I think is a mistake, and I would not
consider its availability as a reason to drop Xnest or Xephyr.

- ajax
___
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

Re: Dropped kdrive == fbdev regression

2017-03-10 Thread Adam Jackson
On Fri, 2017-03-10 at 12:52 +, 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:

- ajax
___
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: [PATCH xserver] Revert "prime: Sync shared pixmap from root window instead of screen pixmap"

2017-03-10 Thread Adam Jackson
On Fri, 2017-03-10 at 11:40 +0900, Michel Dänzer wrote:
> On 09/03/17 08:25 PM, Chris Wilson wrote:
> > This reverts commit b5b292896f647c85f03f53b20b2f03c0e94de428.
> > 
> > This breaks the concept of the screen->pixmap_dirty_list as it no longer
> > tracks the relationship between the PixmapDirtyUpdate src and slave_dst,
> > for the supposed convenience of not tracking present flips.
> 
> Bugzilla: https://bugs.freedesktop.org/100086
> 
> 
> I agree with reverting this on the 1.19 branch, sorry for jumping the
> gun there (I guess I was expecting all drivers to just use
> PixmapSyncDirtyHelper, but of course there's no requirement for that).
> Note that 5c1dd4eba833 ("present: Allow flipping with PRIME slave
> outputs") needs to be reverted first, and then I'd suggest cherry
> picking bb9128fdc86d ("present: disable page flip only when a slave crtc
> is active") to 1.19 instead.

Done, with a fixup to keep dmx building:

To ssh://git.freedesktop.org/git/xorg/xserver
   f23e65f..db1326c  server-1.19-branch -> server-1.19-branch

- ajax
___
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

Dropped kdrive == fbdev regression

2017-03-10 Thread Steven Newbury
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