Re: Some tweaks for smfb(4)

2017-01-09 Thread Mark Kettenis
> Date: Mon, 9 Jan 2017 17:54:53 +0100
> From: Frederic Cambus 
> 
> On Tue, Dec 27, 2016 at 11:39:26PM +0100, Frederic Cambus wrote:
> > 
> > > > Here is a diff with some tweaks for smfb(4):
> > > > 
> > > > - Display resolution and color depth when attaching
> > > 
> > > We should try to do so in a uniform way though.  None of our drivers
> > > print the words "frame buffer".  Most of them only print the
> > > resolution, but I can see the additional value of printing the depth
> > > as well.  Perhaps we should do that for the other framebuffers as well.
> > 
> > All other frame buffer drivers on Loongson (radeonfb and sisfb) print
> > it this way, that's why I used the same scheme here. It seems sgi
> > drivers also do it this way.
> > 
> > I'm all for trying to do things in an uniform way though, and find the
> > formatting used by efifb(4) possibly better: ": %dx%d, %dbpp\n". Any
> > thoughts on this?
> 
> Following up on this, here is a revised version of the diff, which only
> keeps the part adding resolution and color depth display when attaching.
> 
> The output has been updated to follow the efifb(4) scheme.
> 
> Comments? OK?

Not sure introducing the 'fb' local variable makes much sense, but
either way, ok kettenis@

> 
> Index: sys/arch/loongson/dev/smfb.c
> ===
> RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 smfb.c
> --- sys/arch/loongson/dev/smfb.c  21 Oct 2013 10:36:14 -  1.16
> +++ sys/arch/loongson/dev/smfb.c  9 Jan 2017 15:29:54 -
> @@ -202,6 +202,7 @@ void
>  smfb_attach_common(struct smfb_softc *sc, int is5xx, bus_space_tag_t memt,
>  bus_space_handle_t memh, bus_space_tag_t mmiot, bus_space_handle_t mmioh)
>  {
> + struct smfb *fb;
>   struct wsemuldisplaydev_attach_args waa;
>   int console;
>  
> @@ -219,8 +220,9 @@ smfb_attach_common(struct smfb_softc *sc
>   }
>   }
>  
> - /* XXX print resolution */
> - printf("\n");
> + fb = sc->sc_fb;
> + printf(": %dx%d, %dbpp\n",
> + fb->ri.ri_width, fb->ri.ri_height, fb->ri.ri_depth);
>  
>   sc->sc_scrlist[0] = &sc->sc_fb->wsd;
>   sc->sc_wsl.nscreens = 1;
> 



Re: Some tweaks for smfb(4)

2017-01-09 Thread Frederic Cambus
On Tue, Dec 27, 2016 at 11:39:26PM +0100, Frederic Cambus wrote:
> 
> > > Here is a diff with some tweaks for smfb(4):
> > > 
> > > - Display resolution and color depth when attaching
> > 
> > We should try to do so in a uniform way though.  None of our drivers
> > print the words "frame buffer".  Most of them only print the
> > resolution, but I can see the additional value of printing the depth
> > as well.  Perhaps we should do that for the other framebuffers as well.
> 
> All other frame buffer drivers on Loongson (radeonfb and sisfb) print
> it this way, that's why I used the same scheme here. It seems sgi
> drivers also do it this way.
> 
> I'm all for trying to do things in an uniform way though, and find the
> formatting used by efifb(4) possibly better: ": %dx%d, %dbpp\n". Any
> thoughts on this?

Following up on this, here is a revised version of the diff, which only
keeps the part adding resolution and color depth display when attaching.

The output has been updated to follow the efifb(4) scheme.

Comments? OK?

Index: sys/arch/loongson/dev/smfb.c
===
RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v
retrieving revision 1.16
diff -u -p -r1.16 smfb.c
--- sys/arch/loongson/dev/smfb.c21 Oct 2013 10:36:14 -  1.16
+++ sys/arch/loongson/dev/smfb.c9 Jan 2017 15:29:54 -
@@ -202,6 +202,7 @@ void
 smfb_attach_common(struct smfb_softc *sc, int is5xx, bus_space_tag_t memt,
 bus_space_handle_t memh, bus_space_tag_t mmiot, bus_space_handle_t mmioh)
 {
+   struct smfb *fb;
struct wsemuldisplaydev_attach_args waa;
int console;
 
@@ -219,8 +220,9 @@ smfb_attach_common(struct smfb_softc *sc
}
}
 
-   /* XXX print resolution */
-   printf("\n");
+   fb = sc->sc_fb;
+   printf(": %dx%d, %dbpp\n",
+   fb->ri.ri_width, fb->ri.ri_height, fb->ri.ri_depth);
 
sc->sc_scrlist[0] = &sc->sc_fb->wsd;
sc->sc_wsl.nscreens = 1;



Re: Some tweaks for smfb(4)

2016-12-27 Thread Frederic Cambus
On Mon, Dec 19, 2016 at 12:21:54PM +0100, Mark Kettenis wrote:

> > Here is a diff with some tweaks for smfb(4):
> > 
> > - Display resolution and color depth when attaching
> 
> We should try to do so in a uniform way though.  None of our drivers
> print the words "frame buffer".  Most of them only print the
> resolution, but I can see the additional value of printing the depth
> as well.  Perhaps we should do that for the other framebuffers as well.

All other frame buffer drivers on Loongson (radeonfb and sisfb) print
it this way, that's why I used the same scheme here. It seems sgi
drivers also do it this way.

I'm all for trying to do things in an uniform way though, and find the
formatting used by efifb(4) possibly better: ": %dx%d, %dbpp\n". Any
thoughts on this?

> > - Do not hardcode 'wantrows' and 'wantcols' when calling rasops_init
> 
> That is undesirable.  The whole idea here is to put some fixed limits
> on the number of rows and colums such that the lines don't get
> insanely long and scrolling doesn't get too slow because the number of
> rows is ridiculously large.
> 
> If you are concerned about the framebuffer console only using a
> limited part of the screen, see my reply to reyk@ from last week.

In this case, the opposite: smfb assumes a fixed 1024x600 or 800x480
resolution so the hardcoded values are too large. On sgi, some drivers
divide screen width and height by the size of the smallest possible
usable font (8x8), so that was the idea.

> Basically, we need to add a bigger console font.

That makes sense, and this is something I'm interested in working on.
I recently imported psftools in ports to be able to start converting
some fonts and started experimenting.



Re: Some tweaks for smfb(4)

2016-12-19 Thread Mark Kettenis
> Date: Mon, 19 Dec 2016 11:07:19 +0100
> From: Frederic Cambus 
> 
> Hi tech@,
> 
> Here is a diff with some tweaks for smfb(4):
> 
> - Display resolution and color depth when attaching

We should try to do so in a uniform way though.  None of our drivers
print the words "frame buffer".  Most of them only print the
resolution, but I can see the additional value of printing the depth
as well.  Perhaps we should do that for the other framebuffers as well.

> - Do not hardcode 'wantrows' and 'wantcols' when calling rasops_init

That is undesirable.  The whole idea here is to put some fixed limits
on the number of rows and colums such that the lines don't get
insanely long and scrolling doesn't get too slow because the number of
rows is ridiculously large.

If you are concerned about the framebuffer console only using a
limited part of the screen, see my reply to reyk@ from last week.
Basically, we need to add a bigger console font.

> Index: sys/arch/loongson/dev/smfb.c
> ===
> RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v
> retrieving revision 1.16
> diff -u -p -r1.16 smfb.c
> --- sys/arch/loongson/dev/smfb.c  21 Oct 2013 10:36:14 -  1.16
> +++ sys/arch/loongson/dev/smfb.c  18 Dec 2016 22:51:52 -
> @@ -202,6 +202,7 @@ void
>  smfb_attach_common(struct smfb_softc *sc, int is5xx, bus_space_tag_t memt,
>  bus_space_handle_t memh, bus_space_tag_t mmiot, bus_space_handle_t mmioh)
>  {
> + struct smfb *fb;
>   struct wsemuldisplaydev_attach_args waa;
>   int console;
>  
> @@ -219,8 +220,9 @@ smfb_attach_common(struct smfb_softc *sc
>   }
>   }
>  
> - /* XXX print resolution */
> - printf("\n");
> + fb = sc->sc_fb;
> + printf(": %dx%dx%d frame buffer\n",
> + fb->ri.ri_width, fb->ri.ri_height, fb->ri.ri_depth);
>  
>   sc->sc_scrlist[0] = &sc->sc_fb->wsd;
>   sc->sc_wsl.nscreens = 1;
> @@ -413,7 +415,7 @@ smfb_setup(struct smfb *fb, bus_space_ta
>   ri->ri_bpos = 0;
>  #endif
>  
> - rasops_init(ri, 160, 160);
> + rasops_init(ri, ri->ri_height / 8, ri->ri_width / 8);
>  
>   strlcpy(fb->wsd.name, "std", sizeof(fb->wsd.name));
>   fb->wsd.ncols = ri->ri_cols;
> 
> 



Some tweaks for smfb(4)

2016-12-19 Thread Frederic Cambus
Hi tech@,

Here is a diff with some tweaks for smfb(4):

- Display resolution and color depth when attaching
- Do not hardcode 'wantrows' and 'wantcols' when calling rasops_init

Comments? OK?

Index: sys/arch/loongson/dev/smfb.c
===
RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v
retrieving revision 1.16
diff -u -p -r1.16 smfb.c
--- sys/arch/loongson/dev/smfb.c21 Oct 2013 10:36:14 -  1.16
+++ sys/arch/loongson/dev/smfb.c18 Dec 2016 22:51:52 -
@@ -202,6 +202,7 @@ void
 smfb_attach_common(struct smfb_softc *sc, int is5xx, bus_space_tag_t memt,
 bus_space_handle_t memh, bus_space_tag_t mmiot, bus_space_handle_t mmioh)
 {
+   struct smfb *fb;
struct wsemuldisplaydev_attach_args waa;
int console;
 
@@ -219,8 +220,9 @@ smfb_attach_common(struct smfb_softc *sc
}
}
 
-   /* XXX print resolution */
-   printf("\n");
+   fb = sc->sc_fb;
+   printf(": %dx%dx%d frame buffer\n",
+   fb->ri.ri_width, fb->ri.ri_height, fb->ri.ri_depth);
 
sc->sc_scrlist[0] = &sc->sc_fb->wsd;
sc->sc_wsl.nscreens = 1;
@@ -413,7 +415,7 @@ smfb_setup(struct smfb *fb, bus_space_ta
ri->ri_bpos = 0;
 #endif
 
-   rasops_init(ri, 160, 160);
+   rasops_init(ri, ri->ri_height / 8, ri->ri_width / 8);
 
strlcpy(fb->wsd.name, "std", sizeof(fb->wsd.name));
fb->wsd.ncols = ri->ri_cols;