From ffjeld at common-lisp.net  Sun Apr  1 16:05:49 2007
From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld)
Date: 01 Apr 2007 18:05:49 +0200
Subject: [movitz-devel] Re: French (azerty) keyboard layout
References: <87fy7l9lnk.fsf@grigri.elcforest>
Message-ID: <2htzw0cc6a.fsf@vserver.cs.uit.no>

Philippe Brochard <pbrochard at common-lisp.net> writes:

> Attached is a french keyboard layout for movitz. Like qwerty or dvorak
> but for french people.
> 
> Hope that can be useful.

Thanks for that, it's checked into CVS now.

-- 
Frode Vatvedt Fjeld



From sabetts at vcn.bc.ca  Thu Apr  5 00:41:01 2007
From: sabetts at vcn.bc.ca (Shawn Betts)
Date: Wed, 4 Apr 2007 17:41:01 -0700
Subject: [movitz-devel] scheduler patch
Message-ID: <62e3e0b30704041741q6fb0e3afl26fae6133c7c2e89@mail.gmail.com>

Hi Frode,

Here's my scheduler patch. Woven into it is a better keyboard interrupt
handler.

There are 2 things that I'm a bit iffy about:

* the package it's in

* that there's a seperate class, process, instead of wrapper get/set
function around
  (%run-time-context-slot target-rtc <slot>). Maybe making a new
  class is the right way, but this seemed tempting, if I
  understand it properly.

-Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20070404/1781b3f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scheduler.patch
Type: application/octet-stream
Size: 25597 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20070404/1781b3f7/attachment.obj>

From mbealby at gmail.com  Fri Apr 27 20:46:23 2007
From: mbealby at gmail.com (M Bealby)
Date: Fri, 27 Apr 2007 21:46:23 +0100 (BST)
Subject: [movitz-devel] PCI Device Enumeration
Message-ID: <20070427.214623.92584792.mbealby@gmail.com>

Hey all,

I've been thinking about device drivers (again) and I'm wondering what thoughts
people have on PCI device enumeration?

Devices are identified through two identifiers (vendor ID, device ID) supplied
from each card to the PCI controller.  Movitz can already read these
identifiers (see scan-pci-bus).

As far as I can see, there are two approaches we can take here.  We either have
each driver read all the PCI identifiers and initialize devices upon a match,
or we have a 'driver loader' which will parse the pci identifiers once and load
the relevant drivers.  Personally I'm tending towards the latter, but I would
welcome anyones thoughts.

Martin


From sabetts at vcn.bc.ca  Fri Apr 27 22:52:09 2007
From: sabetts at vcn.bc.ca (Shawn Betts)
Date: Fri, 27 Apr 2007 15:52:09 -0700
Subject: [movitz-devel] PCI Device Enumeration
In-Reply-To: <20070427.214623.92584792.mbealby@gmail.com>
References: <20070427.214623.92584792.mbealby@gmail.com>
Message-ID: <62e3e0b30704271552r39f8886es2cb66c0b2a0b16b2@mail.gmail.com>

Hi Martin,

I don't wanna burst bubbles here, but, I would be more interested
to see a PCI device driver written. Even the simplest one would
do...How they get initialized sorta seems maybe secondary to the Meat
of the matter :).

-Shawn

On 4/27/07, M Bealby <mbealby at gmail.com> wrote:
>
> Hey all,
>
> I've been thinking about device drivers (again) and I'm wondering what
> thoughts
> people have on PCI device enumeration?
>
> Devices are identified through two identifiers (vendor ID, device ID)
> supplied
> from each card to the PCI controller.  Movitz can already read these
> identifiers (see scan-pci-bus).
>
> As far as I can see, there are two approaches we can take here.  We either
> have
> each driver read all the PCI identifiers and initialize devices upon a
> match,
> or we have a 'driver loader' which will parse the pci identifiers once and
> load
> the relevant drivers.  Personally I'm tending towards the latter, but I
> would
> welcome anyones thoughts.
>
> Martin
> _______________________________________________
> movitz-devel site list
> movitz-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20070427/421ad058/attachment.html>

From mbealby at gmail.com  Sat Apr 28 10:13:40 2007
From: mbealby at gmail.com (M Bealby)
Date: Sat, 28 Apr 2007 11:13:40 +0100 (BST)
Subject: [movitz-devel] PCI Device Enumeration
In-Reply-To: <62e3e0b30704271552r39f8886es2cb66c0b2a0b16b2@mail.gmail.com>
References: <20070427.214623.92584792.mbealby@gmail.com>
	<62e3e0b30704271552r39f8886es2cb66c0b2a0b16b2@mail.gmail.com>
Message-ID: <20070428.111340.92582782.mbealby@gmail.com>

From: "Shawn Betts" <sabetts at vcn.bc.ca>
Subject: Re: [movitz-devel] PCI Device Enumeration
Date: Fri, 27 Apr 2007 15:52:09 -0700

> Hi Martin,
> 
> I don't wanna burst bubbles here, but, I would be more interested
> to see a PCI device driver written. Even the simplest one would
> do...How they get initialized sorta seems maybe secondary to the Meat
> of the matter :).
> 
> -Shawn
> 


<bang!> :P


This morning i've just realised that the difference between self probing and a
driver loader is minimal.  Should a driver be loaded through its own a probe
routine or a driver loader, the net result is still passing parameters to an
initialistion function.


As for drivers, I have half finished (yet untested) drivers for a couple of
devices ported from other projects, although time is short at the moment.
Hopefully I will get them into a workable state soon.


/me goes back to his driver coding.


Martin


From mbealby at gmail.com  Sun Apr 29 09:58:35 2007
From: mbealby at gmail.com (M Bealby)
Date: Sun, 29 Apr 2007 10:58:35 +0100 (BST)
Subject: [movitz-devel] Graphics APIs and layers
Message-ID: <20070429.105835.74754632.mbealby@gmail.com>

Hi all,

Rather than putting this straight onto the wiki I thought I would throw it out
there to the rest of the developers first.

I have my very basic VMWare graphics driver working (thanks to some lisp help
from frodef last night).  Currently it can change video mode and returns the
address of the linear framebuffer, although the accelerated functions should be
fairly easy to implement.

We currently have a number of graphics drawing functions in vga.lisp.  These
support the vga driver, and similar ones can be created for the vmware driver.

What I'm after is the layer above.  For example, a 'generic' line drawing
functions which will pass down to the correct video drivers line drawing
function (to take advantage of any acceleration support).

I know I could do this with function pointers in C, but I do not know the lisp
equivalent.  If someone could point me to the right areas I will read up on
those sections to have a go at an abstraction layer.

The other question is what features do people want / need in the graphics API
layer?

I have the following list so far:

  * Line / polyline drawing
  * Circle drawing (filled / unfilled)
  * Rectangle drawing (filled / unfilled)
  * Resolution (get / set)
  * Individual pixel (get / set)
  * Viewport (get / set)
  * Buffer flips
  * Surfaces
  * (Text)

I envisage the graphics API to use as much hardware acceleration as possible.
To this effect I also suggest all drawing to occur on video memory surfaces if
available (similar to SDL) -- hence the surface routines.  The net result of
this (apart from using all the hardware scaling etc.) is windows in a future
GUI can just be blitted to the screen similar to OS X.

Any thoughts would be much appreciated,
Martin