Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Geert U. <ge...@li...> - 2001-08-20 13:10:38
|
On Mon, 20 Aug 2001, Adam J. Richter wrote:
> >> = Geert Uytterhoeven
> > = James Simmons
>
> >> What's wrong with the ancient console ioctl()s to change the font at runtine?
> >> (damned, I can't remember the name of the command)
> >
> >Their is a bunch of them but the one mosted used is KD_FONT_OP_*. Look at
> >linux/kd.h for more details. The nice bonus about this is that it is
> >driver independent.
>
> Are there currently GPL-compatible utilities written that
> can load the fonts this way? Are the specific fonts that are in the stock
Yes, setfont in console-tools (not sure about GPL, may be a different license).
> kernel tree in linux/drivers/video/font_*.c available in this format?
I don't think so.
Fonts are in /usr/share/consolefonts/ on my (Debian) system.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Adam J. R. <ad...@yg...> - 2001-08-20 12:49:29
|
>> = Geert Uytterhoeven > = James Simmons >> What's wrong with the ancient console ioctl()s to change the font at runtine? >> (damned, I can't remember the name of the command) > >Their is a bunch of them but the one mosted used is KD_FONT_OP_*. Look at >linux/kd.h for more details. The nice bonus about this is that it is >driver independent. Are there currently GPL-compatible utilities written that can load the fonts this way? Are the specific fonts that are in the stock kernel tree in linux/drivers/video/font_*.c available in this format? If not, I might be willing to help accomplish this. Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 ad...@yg... \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." |
|
From: James S. <jsi...@tr...> - 2001-08-19 14:12:16
|
See Geerts email about the proper solution. The only reason we have font images in the kernel is because fbdev devices usually don't have hardware fonts. Otherwise we wouldn't have them here. Personally I like to seem them __initdata so they go away after boot time. |
|
From: James S. <jsi...@tr...> - 2001-08-19 14:08:52
|
> What's wrong with the ancient console ioctl()s to change the font at runtine? > (damned, I can't remember the name of the command) Their is a bunch of them but the one mosted used is KD_FONT_OP_*. Look at linux/kd.h for more details. The nice bonus about this is that it is driver independent. |
|
From: Geert U. <ge...@li...> - 2001-08-19 11:00:28
|
On Sun, 19 Aug 2001, Adam J. Richter wrote:
> >What's wrong with the ancient console ioctl()s to change the font at runtine?
> >(damned, I can't remember the name of the command)
>
> I don't know enough about fbdev vs. the old PC VGA console
> to know whether those ioctl's are available for fbdev.
Yes, they should work, through the console->con_font_op() call.
> As far as I'm concerned, loading fonts by user level programs
> would be even better than by loading modules, although, I think that,
> when trying to move a facility from kernel to userland, people are a
> lot more willing to try that change if the kernel-based way is still
> available, but normally just compiled as modules that people gradually
> stop using.
Yes, and the user-land support is even older than the kernel support, except
for the one builtin font that fbdev requires (on VGA text the font is in the
VGA BIOS ROM).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Adam J. R. <ad...@ns...> - 2001-08-19 10:29:02
|
>What's wrong with the ancient console ioctl()s to change the font at runtine? >(damned, I can't remember the name of the command) [...] >Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... I don't know enough about fbdev vs. the old PC VGA console to know whether those ioctl's are available for fbdev. As far as I'm concerned, loading fonts by user level programs would be even better than by loading modules, although, I think that, when trying to move a facility from kernel to userland, people are a lot more willing to try that change if the kernel-based way is still available, but normally just compiled as modules that people gradually stop using. Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 ad...@yg... \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." |
|
From: Geert U. <ge...@li...> - 2001-08-19 09:54:10
|
On Sun, 19 Aug 2001, Adam J. Richter wrote:
> Here is my first pass at modularizing the framebuffer console
> fonts. The benefits of this change are primarily for users who
> compile more than just the default console font in their kernel:
>
> o Saves unswappable kernel memory.
>
> o Enables smaller boot floppies (more drivers) and boot partitions.
>
> o At least after I get font unloading working, it will make
> it feasible to upgrade console font modules without
> rebooting.
What's wrong with the ancient console ioctl()s to change the font at runtine?
(damned, I can't remember the name of the command)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: Adam J. R. <ad...@yg...> - 2001-08-19 08:56:57
|
Here is my first pass at modularizing the framebuffer console
fonts. The benefits of this change are primarily for users who
compile more than just the default console font in their kernel:
o Saves unswappable kernel memory.
o Enables smaller boot floppies (more drivers) and boot partitions.
o At least after I get font unloading working, it will make
it feasible to upgrade console font modules without
rebooting.
With this change, you do not have to have all of the console
fonts that you would ever want to use without rebooting locked into
kernel memory. Instead, you can just load the fonts that to use
and still have the possibility to load other fonts later if you want.
One big deficiency with this code is that it will
not allow you to unload a font once it has been used, because I
have not added any calls to my new release_font() routine. However,
this is still no worse than the status quo.
fbcon_find_font will now attempt to use modprobe to load
a font that it fails to find; however, since the font names do not
currently match the module names, you will need to edit your
/etc/modules.conf file to make this work. Also, this functionality
does not currently extend to fbcon_get_default_font, since it does
not take a font name, although I could add a request_module("default_font")
for users to define in /etc/modules.conf if they want, if nothing
smarter can be done.
All that I know about behavior of this patch right now is that
it does not break my VGA console (which does not use these fonts, to
the best of my knowledge). Since this new code causes fonts to
initialized by module_init() declarations, and those routines are
called rather late in kernel initialization, I suspect that there
may be order of initialization problem with that, and would
appreciate confirmation.
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
ad...@yg... \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
|
|
From: Paul M. <le...@Ch...> - 2001-08-11 07:51:27
|
On Sat, Aug 11, 2001 at 01:58:17AM -0400, David T Eger wrote: > I'm developing a framebuffer driver for embedded PowerPC where the > framebuffer resides in system RAM. I'd like to follow what the arm branch > does in their sa1100fb.c driver and do the following: > > (1) call alloc_pages(GFP_KERNEL|GFP_DMA, order) to get a chunk of ram > (2) call free_page() repeatedly on the extra that I won't use > (3) call mem_map_reserve() on all of the pages I am using > (4) call memremap() to remap this to a high virtual address that is marked > non-cacheable > (5) poke around at this remapped area in my graphics code. > > I tried this, but am getting data TLB misses. Am I missing > something? I'm running on a 2.4.2 derived kernel that's been patched by > Montavista. > Which embedded PowerPC is this? For MPC823 (RPXLite and LinuxPlanet) the base address is also retrieved from a chunk of memory, but it's done a little differently then how SA-1100 FB and what you're describing do it. The size is the line length * width, rounded to the nearest full page, and then handed off to alloc_bootmem_pages(). The result from that becomes the base address of the frame buffer. (Calling virt_to_phys() and such where necessary). The only catch is is that allocation should happen relatively early. In the case of the MPC823, page allocation was done in m8xx_setup_arch(). Regards, -- Paul Mundt <le...@ch...> |
|
From: David T E. <eg...@cc...> - 2001-08-11 05:58:24
|
I'm developing a framebuffer driver for embedded PowerPC where the framebuffer resides in system RAM. I'd like to follow what the arm branch does in their sa1100fb.c driver and do the following: (1) call alloc_pages(GFP_KERNEL|GFP_DMA, order) to get a chunk of ram (2) call free_page() repeatedly on the extra that I won't use (3) call mem_map_reserve() on all of the pages I am using (4) call memremap() to remap this to a high virtual address that is marked non-cacheable (5) poke around at this remapped area in my graphics code. I tried this, but am getting data TLB misses. Am I missing something? I'm running on a 2.4.2 derived kernel that's been patched by Montavista. Thanks so much, David Eger |
|
From: Paul M. <le...@Ch...> - 2001-08-10 03:03:16
|
On Thu, Aug 09, 2001 at 03:25:44PM -0700, James Simmons wrote: > > The docs for the aty128fb states that it only supports the Rage128 based > > devices. You sure it's also for the radeon? > > aty128fb does NOT work for the radeon cards!!! Their is a radeonfb.c > driver out their somewhere. I have seen it before. > There is indeed a radeonfb. It's in Alan's tree, has been for awhile. Regards, -- Paul Mundt <le...@ch...> |
|
From: James S. <jsi...@tr...> - 2001-08-09 22:25:52
|
> The docs for the aty128fb states that it only supports the Rage128 based > devices. You sure it's also for the radeon? aty128fb does NOT work for the radeon cards!!! Their is a radeonfb.c driver out their somewhere. I have seen it before. |
|
From: Gioele B. <de...@gi...> - 2001-08-09 14:12:23
|
On Thursday 09 August 2001 07:33, you wrote:
> > From: Gioele Barabucci <de...@gi...>
> > Subject: [Linux-fbdev-devel] Why .C extension?
> >
> > I see that in the subdirs the files are named .C like cpp sources and
> > are=3D =3D20
> > also compiled with g++. Why? Just to use the // comments?
>
> A good place to find your answers will be: man gcc or info gcc.
all I got is:
`FILE.cc'
`FILE.cxx'
`FILE.cpp'
`FILE.C'
C++ source code which must be preprocessed. Note that in `.cxx',
the last two letters must both be literally `x'. Likewise, `.C'
refers to a literal capital C.
`-C'
Rename files to end in `.C' instead of `.c'. This is convenient
if you are converting a C program to C++. This option applies
only to `protoize'.
Can you point me to something more specific?
Is there a conversion to C++ in progress? list.C ando other files in lib/=
=20
use classes.
I also see some classes in include/{framebuffer,database}.h...
--=20
Gioele Barabucci (Gb])
) mailto:de...@gi...
) http://www.gioelebarabucci.com
) ) I've been and now I've gone
) ) /Magic Pie^Oasis
|
|
From: Nicu P. <pa...@ra...> - 2001-08-09 05:52:05
|
> From: Gioele Barabucci <de...@gi...> > Subject: [Linux-fbdev-devel] Why .C extension? > > I see that in the subdirs the files are named .C like cpp sources and are= > =20 > also compiled with g++. Why? Just to use the // comments? A good place to find your answers will be: man gcc or info gcc. -- Nicu Pavel. |
|
From: Gioele B. <de...@gi...> - 2001-08-08 10:51:34
|
I see that in the subdirs the files are named .C like cpp sources and are= =20 also compiled with g++. Why? Just to use the // comments? --=20 Gioele Barabucci (Gb]) ) mailto:de...@gi... ) http://www.gioelebarabucci.com ) ) I've been and now I've gone ) ) /Magic Pie^Oasis |
|
From: James S. <jsi...@tr...> - 2001-08-06 17:32:32
|
> I contacted Geert Uytterhoeven and he pointed me to this list. > I asked him about fbutils and he told me that it is not yes on the CVS. > Could someone commit it so I can give it a look (I already have the 1999 > tarball...)? export CVS_RSH=ssh cvs -d:pserver:ano...@cv...:/cvsroot/linux-fbdev login cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linux-fbdev co fbutils |
|
From: Gioele B. <de...@gi...> - 2001-08-04 18:17:28
|
Hi, I am I newbie linux programmer. I like very much framebuffer and=20 everything that is around it (SDL - Qt/E mainly). I contacted Geert Uytterhoeven and he pointed me to this list. I asked him about fbutils and he told me that it is not yes on the CVS. Could someone commit it so I can give it a look (I already have the 1999=20 tarball...)? --=20 Gioele Barabucci (Gb]) ) mailto:de...@gi... ) http://www.gioelebarabucci.com ) ) I've been and now I've gone ) ) /Magic Pie^Oasis |
|
From: Romain D. <do...@ir...> - 2001-08-02 07:47:40
|
chr...@ph... wrote: > So in Ex1 why not defining the sa1100fb_hwswitch variable ??? > > Or when do you define xxxxfb_hwswitch variable and put fbgen_xxx > functions in xxxxfb_ops var (like ex2) rather than writing > function for only xxxxfb_ops (like ex 1) ? Well, in the 2.4.x API you have two way of doing thing: 1) do everything by hand, as in the sa1100 example. you need to fill the fb_ops struct and write the relevant functions. 2) let fbgen do a bit of thw work for you. Then, you fill fb_ops with the fbgen functions. The fbgen fucntions will need some support functions, and those are in the fbgen_hwswitch struct. It's the way it's done in pm2fb or pm3fb. In the newer 'ruby' framework, the functions you need to write are similar to those in case 2) above (mostly hardware stuff, no console stuff), but they go in the fb_ops struct :-) HTH -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Ghozlane T. <gt...@me...> - 2001-08-01 13:11:40
|
Hi, At last I took time to release a more or less working version of sstfb, a driver for the old/dead but once famous 3Dfx 3D "only" chips, namely the voodoo graphics and the voodoo2 . A small problem (basicaly awfully outdated an unmaitained machine , my fault) did'nt allow me to test it myself with 2.4 kernels , but i have a very good tester, and it seems that the driver works more or less with 2.4, with some issues: when using X fbdev 4 (on linux2.4), killing X may oops, and lives the console with strange palette (in addition to strange colors in windows border colors). (a reminder that this driver is still experimental) . On 2.2.19 everything looks ok, even with X. (Well, at least an X from the 3.3.x awfully old fame). I'm trying to investigate the problems, but as I'm unable to reproduce myself, it's not that easy. The next step is rebuilding my machine with an up-to-date distribution and take a look at the 2.4 / X4 issues. Meanwhile, the latest "kinda stable" (read no oops/crash on my box) version is avaiable for 2.2.19, 2.4.7 and 2.4.7-ac3 on sourceforge : http://prdownloads.sourceforge.net/sstfb/sstfb-20010801.tgz . for the patches only , look at the download page directly : http://sourceforge.net/projects/sstfb/files . I'm looking for good willing people to take a look at the driver and flame me at sight, and if i'm lucky, I'd like to increase a little bit the testing base for the thing (3 testers + me so far) Thank you very much , ghoz PS please CC me on eventual replies as I may not be able to follow the lists in the folowing days |
|
From: thomas s. <ts...@ko...> - 2001-07-31 08:06:51
|
Hi! I'd like to chnage the FB logo at boot time. I tried to compil the fb tool pnmtologo. But wereas I get all necessary lib, it failed. So my question is: does someone uses this little prog and can send me a static compiled version or generate a logo for me (I'll send the pnm or png file). Thanks in advance. Tom |
|
From: Paul M. <le...@Ch...> - 2001-07-30 01:06:06
|
On Sat, Jul 28, 2001 at 04:21:17PM -0500, Steven Walter wrote: > I have created a patch that changes the 3dfx framebuffer driver so that > it uses the new-style PCI api. Additionally, it adds the ability to > pass parameters to the module (previously these were only availible when > built into the kernel) and makes the indention conformant to > Coding-Style. > > I've tested it myself as both module and built-in with no problems, but > you can never test too much. I'd like to ask adventuresome users of > this driver to try out my patch, with the hopeful end result of > inclusion into the kernel. > > The patch is availible from: > http://www.apex.net/users/trwalter/tdfxfb-patch.gz > Its 22k compressed (large because of style/indention changes), so I was > hesitant to post it to the list. > Looks good for the most part, but maybe we could do without the excessive white space changes? How about something more like the attached patch? Regards, -- Paul Mundt <le...@ch...> |
|
From: Russ D. <Rus...@as...> - 2001-07-27 19:09:21
|
I'm working with an arch that uses the sa1100fb and has seperate hardware to control the backlight power, intensity, and brightness. I realize there are many boards out there that have a backlight that is associated with their framebuffer (in the case of LCD's). I was wondering how to best implement userspace control of the backlight. Should there be new fd ioctl's? Should there be a proc interface? Should the backlight get its own major or minor and be conmpletely seperate from the framebuffer? Lemme know what you think (cc me because I'm not subscribed) |
|
From: <chr...@ph...> - 2001-07-26 07:45:31
|
Hello,
I have to write a fb (!?) on embedded system. I will certainly reuse the sa1100fb.c frame buffer.
Can someone explain the difference between the following examples :
In some framebuffer drivers there is :
either:
************************* Ex 1
(from sa1100fb.c)
static struct fb_ops sa1100fb_ops = {
owner: THIS_MODULE,
fb_get_fix: sa1100fb_get_fix,
fb_get_var: sa1100fb_get_var,
fb_set_var: sa1100fb_set_var,
fb_get_cmap: sa1100fb_get_cmap,
fb_set_cmap: sa1100fb_set_cmap,
};
with sa1100fb_encode_fix(), sa1100fb_getcolreg(), sa1100fb_setcolreg() etc, defined which could belong to the fbgen_hwswitch struct.
or:
************************* Ex 2
(from pm2fb.c)
static struct fbgen_hwswitch pm2fb_hwswitch={
pm2fb_detect, pm2fb_encode_fix, pm2fb_decode_var,
pm2fb_encode_var, pm2fb_get_par, pm2fb_set_par,
pm2fb_getcolreg, pm2fb_setcolreg, pm2fb_pan_display,
pm2fb_blank, pm2fb_set_disp
};
static struct fb_ops pm2fb_ops={
owner: THIS_MODULE,
fb_get_fix: fbgen_get_fix,
fb_get_var: fbgen_get_var,
fb_set_var: fbgen_set_var,
fb_get_cmap: fbgen_get_cmap,
fb_set_cmap: fbgen_set_cmap,
fb_pan_display: fbgen_pan_display,
};
___________________________________________________
So in Ex1 why not defining the sa1100fb_hwswitch variable ???
Or when do you define xxxxfb_hwswitch variable and put fbgen_xxx functions in xxxxfb_ops var (like ex2) rather than writing function for only xxxxfb_ops (like ex 1) ?
ThanX
Christophe Levantis
|
|
From: Antonino D. <ad...@po...> - 2001-07-21 16:38:29
|
Hi people! I'm a relatively recent subscriber to this mailing list and by accident discovered that a framebuffer device for the i810 was already being developed. In the meantime, I was also trying to brew a device of my own and it's already functional by the time I happen to find out. Anyways, the device I have made should work in 640-1600 horizontal resolution at 2,4,8 and 16 bpp with unaccelerated and accelerated functions (excluding clear_margins), and mtrr. These options are selectable at kernel boot time. At present, the device will compile with kernel 2.2.19 (I have a very slow modem and still thinking of downloading kernel 2.4.x). To make it work with X, I forego using the kernel agpgart and have the device handle it's own agp allocation routines. However, since there is really no interface between X/agpgart and the framebuffer, switching to and from X and the fb console is still a bit tricky and nearly an ugly hack, but is doable and works almost all of the time (at least in my test box). There are still a few bugs, the most major of which is that X, although will work in its native mode, will NOT work when using fbdev :( (still trying to work on this). There are also initial screen corruptions during transition from standard vga mode to hig! h ! resolution mode, and a few others. I'll probably stop developing this driver (it's a waste of effort) and I would like to contribute patches to the developers of the i810 fb module if the developers will not mind. Who should I send it too? For anyone interested in this driver, please let me know and I'll send a kernel patch/file via e-mail. Sorry, I don't have any access to an ftp or http site. Tony ad...@po... |
|
From: Ghozlane T. <gt...@pr...> - 2001-07-20 19:11:55
|
----- Original Message ----- From: "James Simmons" <jsi...@tr...> Sent: Friday, July 20, 2001 7:38 PM Subject: Re: [Linux-fbdev-devel] how to drop access to an ioremapped area ? > > what if i make glide use a new VC , a la X, and then pray that userland apps > > will play nicely when changing the console, by stopping every write ? > > how does fb apps (from X to fbtv) cope with VC switches ? > > They really don't :-( "ouch" ... is this a definitive limitation/issue, or is the upcomming ruby taking care of this kind of issues ? |
754 messages has been excluded from this view by a project administrator.
