David Brownlee | 20 Sep 2011 18:02
Picon

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

On 20 September 2011 16:38, Michael <macallan1888 <at> gmail.com> wrote:
> Hello,
>
> On Tue, 20 Sep 2011 12:19:29 +1000
> matthew green <mrg <at> eterna.com.au> wrote:
>
>> alpha xorg doesn't work for tga cards, and there is no support
>> for the turbochannel cards.  (someone send a pmax to mac ;)
>
> I had a look at the Xserver code, there's acceleration support for tga and a bunch of others ( presumably
turbochannel ). Shouldn't be too hard to turn into Xorg drivers with the right machine. I have no alpha or
pmax hardware though.

I have a Dec3000 TC alpha here and happy to ship, though postage from
the UK might be a little steep, alternatively I'm more than happy to
cover postage for a closer machine...

If you were likely to be able to find time to look at xorg on alpha or
pmax I'm sure there would be no shortage of people on the relevant
port-* lists willing to spare a box :)

Michael | 21 Sep 2011 16:35
Picon
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

Hello,

On Wed, 21 Sep 2011 11:52:22 +0200
Frank Wille <frank <at> phoenix.owl.de> wrote:

> BTW, does a normal Xorg driver require a wscons/wsdisplay, or can it be
> started completely independant of the console (ite, wscons, or whatever) ?

Most drivers do not depend on wsdisplay, and those which do are things like crime ( which can't be probed
through some sort of bus so it uses /dev/ttyE0 to talk to the kernel driver ) and wsfb ( obviously )
The mouse and keyboard drivers pretty much require wscons though.

> I would prefer to have wsdisplay drivers for all seven Amiga graphics
> cards first. This is even something I would be capable doing, or at least
> helping with, in constrast to an Xorg driver...

If you have a mappable framebuffer then attaching a wsdisplay on top of it is pretty much trivial. The only
problem I see is with the Amiga's built-in graphics hardware which doesn't give us packed pixels as far as I know.

> A typical NetBSD/amiga user will have a special Amiga graphics card
> (usually CirrusLogic or S3 based) in a Zorro3 slot.

Xorg has drivers for both, adding support for Z3 on top of PCI would not be that hard. Or one could do what I did
with the ag10e driver - take the chip-specific part and stick it in a new driver that knows about the new bus,
maps stuff etc. so the rest of the driver can work.
( Fujitsu's AG-10e is a monstrosity that hides a bunch of PCI graphics chips behind a custom made and
completely undocumented SBus-PCI bridge. Luckily the firmware tells us where to find the various memory
and register ranges belonging to the individual chips so getting it to work wasn't that hard - just
couldn't treat them as PCI. )
I suspect the Cirrus and S3 chips mentioned above will be VLB or PCI variants with some Z3-specific glue logic.
(Continue reading)

Radoslaw Kujawa | 22 Sep 2011 12:32
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)


On 22 wrz 2011, at 11:35, Frank Wille wrote:
> Maybe we should just include some fixed VESA modes in wsdisplay instead?

Indeed. These modes could be shared by many drivers. 

>> The only problem I see is with the
>> Amiga's built-in graphics hardware which doesn't give us packed
>> pixels as far as I know.
> 
> True. But IMHO this is not extremely important to support. I doubt that
> many people want to run X in flickering 640x400 interlaced at 30Hz.

I used to run X in 640x400 some years ago, it was not flickering! And at about 70Hz ;). Unusable with 68030 due
to performance issues, but quite fine with 68060.

>> I suspect the Cirrus and S3 chips mentioned above will be VLB
>> or PCI variants with some Z3-specific glue logic.
> 
> Exactly.

In fact, most are ancient ISA variants. Only Picasso IV and CV64/3D use PCI chips bridged to Z3. There's also
CVPPC/BVPPC cards which are purely PCI (just with special Amiga-specific connector) and now their
attachment is supported by p5pb(4).

--

-- 
Best regards,
Radoslaw Kujawa

(Continue reading)

Radoslaw Kujawa | 27 Sep 2011 15:37
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

Hi.

On 27 wrz 2011, at 11:37, Frank Wille wrote:
> We probably don't have to care about the fonts, as this is already done
> by the grfxx driver?

I understand that the current font code will not work with wscons. However, wscons does not really care
about this, because it has it's own terminal emulator and own fonts (provided by wsemul). 

> The new wsdisplay-emulops and -accessops code should probably go directly
> into grf_xx.c (enclosed by NWSDISPLAY>0).

I agree with this.

> I don't see how we can use wsfb, though. The genfb driver does not support
> the graphics card's text mode,

It's not really a text mode in VGA/x86 sense of this word. Current grf drivers set up some graphics mode, on
which terminal is emulated (ite) using 2D accelerated drawing routines. Similarly, terminal emulator
is attached on top of wsdisplay driver (genfb in this case). The whole point is that genfb will be slower,
because it does not know about specific capabilities of the used graphics hardware (blitter etc.). So I
don't really like this solution.

> which we need for acceptable performance
> on such slow hardware. Or am I missing something?

I understand that wsfb X11 driver should work on top of _any_ wsdisplay driver that does provide memory
mapped mode. We're not forced to use genfb. I would prefer to add the new methods to every grf driver, to
provide wsdispaly on top of grf.

(Continue reading)

Michael | 27 Sep 2011 16:23
Picon
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

Hello,

> I don't see how we can use wsfb, though. The genfb driver does not support
> the graphics card's text mode, which we need for acceptable performance
> on such slow hardware. Or am I missing something? So we still have the
> problem to make new Xorg drivers.

You can switch to graphics on ioctl(WSDISPLAYIO_SMODE, WSDISPLAYIO_MAPPED) and back on
WSDISPLAYIO_EMUL. Some drivers use it to switch the hardware to 24bit for X while running the console in 8
bit. See cgfourteen, crmfb and ag10e for example.
Also, vcons has a few tricks to speed up dumb framebuffers ( seriously, is the blitter /that/ slow? ) - use
VCONS_DONT_READ ( see for example the genfb, cgfourteen and cgthree drivers ) which eliminates
framebuffer reads and instead just redraws whatever needs to be redrawn from the relevant text buffer
which gives a nice speedup on slow, dumb framebuffers. 
If you run something VGA-ish in text mode you may also want to think about implementing blitter support -
Cirrus and S3 docs shouldn't be that hard to find.
You will want to implement at least an accelerated putchar() using whatever colour expansion scheme your
hardware supports so you don't have to map the framebuffer at all ( and VCONS_DONT_READ with an
accelerated putchar() may scroll faster than the blitter on some old hardware )
I don't know what caching modes the various 68k CPUs support, many more modern ones support something
that's still uncached but allows for write combining, prefetching, relaxed ordering or any combination
thereof, which is useful for accessing device memory ( like framebuffers ). This can be enabled using the
BUS_SPACE_MAP_PREFETCHABLE flag in bus_space_(m)map() if your underlying pmap supports it. I added
support for this on PowerPC ( don't set the G bit for relaxed ordering, buffering etc. ), ARM ( allow write
buffering ), MIPS ( use the 'accelerated' CCA if the CPU supports it ) - if your CPUs have anything like this
you may want to support it, any little speedup helps and on slow hardware with dumb framebuffers it's often
quite noticeable. Even if you have hardware acceleration the Xse
 rver will want to access video memory at some point.

have fun
(Continue reading)

Michael | 27 Sep 2011 16:29
Picon
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

Hello,

On Tue, 27 Sep 2011 15:37:55 +0200
Radoslaw Kujawa <radoslaw.kujawa <at> c0ff33.net> wrote:

> > I don't see how we can use wsfb, though. The genfb driver does not support
> > the graphics card's text mode,
> 
> It's not really a text mode in VGA/x86 sense of this word. Current grf drivers set up some graphics mode, on
which terminal is emulated (ite) using 2D accelerated drawing routines. Similarly, terminal emulator
is attached on top of wsdisplay driver (genfb in this case). The whole point is that genfb will be slower,
because it does not know about specific capabilities of the used graphics hardware (blitter etc.). So I
don't really like this solution.

No need to use genfb at all if you can attach a wsdisplay directly to grf.
As far as I can tell grf already gives you a reasonable abstraction which - as a stopgap measure - can easily be
translated to wsdisplayops in a more or less generic way. That would allow wsdisplay to use whatever
acceleration capabilities ite uses.
Also, wsdisplay with vcons is likely a lot faster than ite on dumb framebuffers.

have fun
Michael

Frank Wille | 27 Sep 2011 17:21
Picon

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

On Tue, 27 Sep 2011 10:23:41 -0400
Michael <macallan1888 <at> gmail.com> wrote:

> You can switch to graphics on ioctl(WSDISPLAYIO_SMODE,
> WSDISPLAYIO_MAPPED) and back on WSDISPLAYIO_EMUL. Some drivers use it
> to switch the hardware to 24bit for X while running the console in 8
> bit.

Ahh! That was the missing piece for my puzzle. Thanks! :)

Does SMODE expect the mapped frame buffer mode to have the same resolution
as the console mode before?

> If you run something VGA-ish in text mode you may also
> want to think about implementing blitter support - Cirrus and S3 docs
> shouldn't be that hard to find.

We can think about that, but the speed for the current grf text consoles
is fine, and we can reuse the code for wsdisplay emulops (or vcons
rasops - I will definitely do vcons!).

All grf devices except one (grful) support a text mode, which only has to
move a character and attribute byte for each position. This is fast enough
with the CPU.

> You will want to implement at least
> an accelerated putchar() using whatever colour expansion scheme your
> hardware supports so you don't have to map the framebuffer at all

As I understand wsdisplay doesn't need to know about the frame buffer
(Continue reading)

Michael | 27 Sep 2011 19:59
Picon
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

Hello,

On Tue, 27 Sep 2011 19:37:03 +0200
Radoslaw Kujawa <radoslaw.kujawa <at> c0ff33.net> wrote:

> On 27 wrz 2011, at 17:27, Frank Wille wrote:
> 
> > Yes, it does not care about it. It just calls putchar() with a text position
> > and our driver has to render the character, just in the same way as it
> > did in the ite driver before. At least I hope so?
> 
> I'm not sure if I am following. Do you want to use existing procedures in grf

Yes :)

> for terminal emulation?

No. Or rather, wsdisplay provides the terminal emulation, grf and the underlying drivers do the drawing.

> If we're going to disconnect ite device, then there will be no putchar function to use (because it is
provided by ite). We need to rewrite it for wsdisplay. 

Huh? Ite draws characters by calling functions provided by grf, wsdisplay can do the same.

have fun
Michael

Michael | 27 Sep 2011 20:31
Picon
Gravatar

Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

Hello,

On Tue, 27 Sep 2011 20:06:45 +0200
Radoslaw Kujawa <radoslaw.kujawa <at> c0ff33.net> wrote:

> 
> On 27 wrz 2011, at 19:59, Michael wrote:
> 
> > Huh? Ite draws characters by calling functions provided by grf, wsdisplay can do the same.
> 
> Typical wsdisplay driver implementation provides functions like putchar, cursor, etc. In grf+ite
combination, these functions are provided by ite. So, if we suddenly don't use ite, then we don't have
access to these functions ;). 

Sorry, I must be missing something since this makes no sense whatsoever.
putchar() is a low level operation that's done by the driver or something else that scribbles into video
memory ( like rasops for example ). Why on earth would anyone put that into the terminal emulator?

have fun
Michael

David Holland | 29 Sep 2011 11:03
Picon

two broken imake settings

(1) in native X, src/external/mit/xorg/share/cf/xorgsite.def contains

   #define HasSecureRPC YES

which is wrong; we don't have "secure" RPC. It is not clear why this
is set; however, it's breaking the build of x11/xdm3d, which uses this
to decide that it should include <rpc/key_prot.h>, which doesn't
exist. There's nothing in the CVS history to suggest why this setting
is present; it's been there since the file was created 3+ years ago.
Is there any reason not to remove it? (IOW, does "HasSecureRPC" mean
something other than what xdm3d thinks it means?)

(2) in both native and pkgsrc X, HasSetUserContext is not defined even
though we have setusercontext(3). It's enabled for FreeBSD, OpenBSD,
and DragonFly, so I assume the answer is yes... for native X, should
it be patched into NetBSD.cf or added to xorgsite.def?

Please keep me in the cc list as I don't ordinarily follow tech-x11.
(Although perhaps I should.)

--

-- 
David A. Holland
dholland <at> netbsd.org


Gmane