an attempt at using both screens

[Salva Peiró]

the following patch contains a another load of changes,
here's is a small enumeration, most relevant first:
- experimental/basic code to use the upper screen
- fixes for reading/writting to sd/tf card
- audio playing and recording
- more code for wifi stats/tx/rx (still not usable)
- add gmtf.c to support the GnM storage card
- more cleanup (lcdreg.h, io.h, arm7/acidmap)

To use both screens just take a look at the end of
archds.c:/^conf.screens, by default the number of screens is set to 1,
setting it to 2 enables the upper screen.
I consider it quite tricky to use, that's why it's not already in the repo.

If someone is interested in giving a try to the wifi code,
take a look at the libnds/dswifi cvs [1] as it has recently added fifo support,
which as a side effect has made the wifi code simpler.

[1] http://sourceforge.net/project/showfiles.php?group_id=114505
--
salva

[Salva Peiró]

yet another attempt, this one look closer to a solution.

--
salva

[Caerwyn Jones]

Here's a snapshot of inferno running dual screen.
http://www.flickr.com/photos/caerwyn/2792682703/
Sorry about poor quality picture, I haven't a good camera.

I quickly run out of memory running any apps because of the larger
image size. And the dual screen is another challenge to wm. Windows
opened in the top screen can not be resized, closed wm. It needs some
custom designed apps to take advantage of it. But I love it. Thanks
again Salva.

Now I just need images with masks to display. It beats me why any
image that has a mask isn't visible.

Caerwyn

[Salva Peiró]

On Sun, Aug 24, 2008 at 8:24 PM, Caerwyn Jones <caer...@gmail.com> wrote:
>
> Here's a snapshot of inferno running dual screen.
> http://www.flickr.com/photos/caerwyn/2792682703/
> Sorry about poor quality picture, I haven't a good camera.
>
> I quickly run out of memory running any apps because of the larger
> image size.

about the memory consumption, right now each pixel is a 16 bit value
(direct color)
one improvement would be to setup a palette of 256 values of 8 bits
this would result in a 50% reduction of the displayed images size.
See http://dev-scene.com/NDS/Tutorials_Day_3 (and Day_4)

> And the dual screen is another challenge to wm. Windows
> opened in the top screen can not be resized, closed wm.
> It needs some custom designed apps to take advantage of it.

I'm thinking about the following to control of the un-touchable screen:
The idea i have is to combine various approaches so
one can use the one that best suits to perform the task,
the main goal is to be easy to use and don't require any special app design.

1) key-combo to make touches in the lower screen refer to the upper.
That's implemented in the previous patches using as a Select+Start key-combo.
2) key-combo to make make both screen's being swapped.

Any other alternatives to consider?

There could be a third which is to between conf.screens = 1 and
conf.screens = 2,
that'll be similar of zoom/unzoom and i don't know if it's implementable
(or worth considering), but doing a few experiments will answer that quickly.

> Now I just need images with masks to display. It beats me why any
> image that has a mask isn't visible.
>

i know little about graphics, but i'll keep an eye on it.

--
salva

[David Leimbach]

On Sun, Aug 24, 2008 at 12:26 PM, Salva Peiró <saore...@gmail.com> wrote:

On Sun, Aug 24, 2008 at 8:24 PM, Caerwyn Jones <caer...@gmail.com> wrote:
>
> Here's a snapshot of inferno running dual screen.
> http://www.flickr.com/photos/caerwyn/2792682703/
> Sorry about poor quality picture, I haven't a good camera.
>
> I quickly run out of memory running any apps because of the larger
> image size.

about the memory consumption, right now each pixel is a 16 bit value
(direct color)
one improvement would be to setup a palette of 256 values of 8 bits
this would result in a 50% reduction of the  displayed images size.
See http://dev-scene.com/NDS/Tutorials_Day_3 (and Day_4)

> And the dual screen is another challenge to wm.  Windows
> opened in the top screen can not be resized, closed wm.
> It needs some custom designed apps to take advantage of it.

I'm thinking about the following to control of the un-touchable screen:
The idea i have is to combine various approaches so
one can use the one that best suits to perform the task,
the main goal is to be easy to use and don't require any special app design.

1) key-combo to make touches in the lower screen refer to the upper.
That's implemented in the previous patches using as a Select+Start key-combo.
2) key-combo to make make both screen's being swapped.

Any other alternatives to consider?

For 2, I see a usage model like the following...

One option is to use each screen as a "desktop", and swap an active one in with a button.  Then you can have a set of windows on top and bottom, and swap them in and out of an active state.

Dave

 

There could be a third which is to between conf.screens = 1 and
conf.screens = 2,
that'll be similar of zoom/unzoom and i don't know if it's implementable
(or worth considering), but doing a few experiments will answer that quickly.

> Now I just need images with masks to display. It beats me why any
> image that has a mask isn't visible.
>

i know little about graphics, but i'll keep an eye on it.

One option is to use each screen as a "desktop", and swap an active one in with a button.  Then you can have a set of windows on top and bottom, and swap them in and out of an active state.

Dave

 

--
salva

[LiteStar numnums]

Well, one quick idea, off the cuff, is to move all window commands, menus, &c. to the second screen, & place a virt keyboard there as well. Something similar to Pictochat. Left & Right could cycle through windows on the top screen, and all Windowing commands would be on the bottom. Potentially quite clunky, but could be interesting. Would give some one the palate space to work on hand writing recognition for inferno, for the truly PDA-focused amongst us.

Just my $0.02.
Cheers,
 -- LS

--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
-- Ovid

"By cosmic rule, as day yields night, so winter summer, war peace, plenty famine. All things change. Air penetrates the lump of myrrh, until the joining bodies die and rise again in smoke called incense."

"Men do not know how that which is drawn in different directions harmonises with itself. The harmonious structure of the world depends upon opposite tension like that of the bow and the lyre."

"This universe, which is the same for all, has not been made by any god or man, but it always has been, is, and will be an ever-living fire, kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[Salva Peiró]

On Sun, Aug 24, 2008 at 10:46 PM, David Leimbach <lei...@gmail.com> wrote:
>
> On Sun, Aug 24, 2008 at 12:26 PM, Salva Peiró <saore...@gmail.com> wrote:
>> Any other alternatives to consider?
>
> For 2, I see a usage model like the following...
> One option is to use each screen as a "desktop", and swap an active one in
> with a button. Then you can have a set of windows on top and bottom, and
> swap them in and out of an active state.
>
> Dave

If i've understood well that would be dealing with windows,
so it i'd be implemented at the level of window manager.

To keep it simple & easy i'd like to focus on alternatives
that can be implemented easily at the kernel level,
in a way that it doesn't interferes with the design of wm(1)
and that of the whole Inferno.

--
salva

[hiro]

> To keep it simple & easy i'd like to focus on alternatives
> that can be implemented easily at the kernel level,
> in a way that it doesn't interferes with the design of wm(1)
> and that of the whole Inferno.

I'm not sure if this is the best way.

The screen is small, so one should use as much real screen estate as possible.
I don't see much use of mainline wm on this platform.

You're doing great work:)

[Salva Peiró]

>
> I'm not sure if this is the best way.
>

i like to be proven wrong either my me or by others,
so just go ahead and implement what you're thinking

--
salva

[hiro]

I'm sorry, I can't give you proof, nor do I have any qualification.
I've just made a lot of positive experiences with a tiling window
manager (wmii) on my small notebook display.
I normaly don't see any floating windows on mobile phones or
comparable small-screen devices, and I guess there is a good reason
behind it: the need of good window management gets greater with
smaller screens.

[David Leimbach]

What was the GUI Caerwyn had wanted to revive?  I didn't think it was wm.

 

[hiro]

> What was the GUI Caerwyn had wanted to revive? I didn't think it was wm.

mux?

[David Leimbach]

On Mon, Aug 25, 2008 at 9:16 AM, hiro <23h...@googlemail.com> wrote:

> What was the GUI Caerwyn had wanted to revive?  I didn't think it was wm.

mux?

Ah right, mux :

http://caerwyn.com/ipn/  

Scroll down a bit you'll see a post about mux for nintendo DS.

 

[David Leimbach]

In fact there's a binary that works for me too :-)

 

 

[LiteStar numnums]

I would have to agree; awesome, ratpoison, stumpwm & dwm work a lot better for me on tiny screens than a 'find start screen & select program' manager. Window functions take up screen space that could be better used for program functionality.
I like the 'put up or shut up' aspect of this thread, so as soon as I get some stuffs I'll start hacking (I've been feeling like Limbo anyway). I think with the right key combos, Inferno could be a PDA-killer of sorts.
 Having controls such as what I described would help with 3d acceleration, which, iirc, can use only one screen at a time; since the top screen would be the dedicated view term, we know where 3d would be used at any given time.

Cheers,
 -- S.

[Charles Forsyth]

>I would have to agree; awesome, ratpoison, stumpwm & dwm work a lot better
>for me on tiny screens than a 'find start screen & select program' manager.

wm is just a (recursive) multiplexor. most aspects of the interface are done by modules elsewhere.

[janis]

Did anybody considered the alternative to use lower screen as a
touchpad? (if it's possible to implement, I mean)

I mean, any movement of stylus on the lowest screen would move the
mouse pointer, so that the mouse pointer is not where the stylus is,
but it's moved by stylus.

In such case both screens will be used the same way, together.

[Caerwyn Jones]

thanks for reminding me. yes, a few changes to wmclient and toolbar
could make wm appear and behave quite different. e.g.
http://flickr.com/photos/caerwyn/64347532/

I am working with mux at the moment. Here's more samples. All this
will be checked in to inferno-lab soon so others can play with it on
the desktop.
http://flickr.com/photos/caerwyn/2797968741/
http://flickr.com/photos/caerwyn/2793920589/
http://flickr.com/photos/caerwyn/2798075737/

Caerwyn

[Salva Peiró]

On Tue, Aug 26, 2008 at 10:36 PM, janis <k0i...@gmail.com> wrote:
>
> Did anybody considered the alternative to use lower screen as a
> touchpad? (if it's possible to implement, I mean)
>
> I mean, any movement of stylus on the lowest screen would move the
> mouse pointer, so that the mouse pointer is not where the stylus is,
> but it's moved by stylus.
>

that sounds interesting!, as it extends easily from one screen to two.
Moreover with the visual feedback of a small mouse cursor
it could be quite easy & handy to use.

--
salva