Virtual frambuffer switching for Kobo

[fastrobot]

Originally Posted by davidfor

But, did you edit executable or configuration files? The latter might be generated at run time by something so we don't want them replaced. If there are executables that are not replaced by an upgrade, that to me is a concern. Or it means they are no longer being used.

I haven't checked all executables though I did chmod busybox, to make it suid root.
eg: Login, passwd, etc. won't work unless it's suid root.
I'm not concerned -- I just didn't want to say "full" upgrade, when it didn't wipe absolutely everything out on the partition and replace it.

The Glo and Aura HD are different hardware.

Mostly they have different wiring. The CPU has general purpose IO's, and from reading a diff of the Glo and Aura kenels, almost all the differences are in which io pin goes to what on the processor. Which mostly means the Engineer laying out the board found it too 'hard' to duplicate the pin assignments from one PCB to the next, or didn't care.

Pin assignments apparently can't be loaded as a kernel module; so basically Kobo was forced to compile the same kernel twice with different #defines for pin definitions.

They share some things, such as the CPU, but other elements are different enough that the upgrade package includes a separate kernel image for the Aura HD, but the Glo, N905C Touch and the Mini share one.

Right. That makes a lot of sense now that I've looked at the code.
Although, it's interesting to note that there are some code changes which look like bug fixes evident in the KoboAuraHD's version of the zforce-ir-touch driver, and in the epaper display driver (besides just macro definitions for the resolution change).

The hardware interface on those devices is essentially the same, so that the code didn't really need to change beyond setting a different screen resolution; but I'm guessing that historically, the Glo is an older device than the AuraHD and the engineers realized there were minor hardware problems based on what I see in the driver code.

I'm also noticing that the values sent to the Kobo Glo for frontlight illumination start much higher in the Glo than on the Aura. Considering it's the same MSP430 driving the frontlight, that makes me wonder if replacing the Glo's lighting table with the Aura's would allow me to dim the screen more. I'll have to experiment with that later when I'm not pressed for time.

Overall, it doesn't really look like KOBO has updated the kernels since the devices were released ; It's more of a test, once it's working and in production -- keep it that way....

You can't do a dd of the recovery partition to the root partition as there is code to execute the reinstall. You would need to remove that afterwards. In any case, the factory reset does install a copy of the uBoot and kernel. And everything else.

OK. Although it's not impossible to do a dd in general, the way Kobo wrote the script is perhaps not intelligent enough to detect by an 'if' statement which partition it is running from and behave accordingly -- but OK, it's more important to understand what they did than what they could have done.

But taking a copy of the SD card will save you if you make a mistake.

Yep. DId that... cloned to my hard drive. Probably should back up the hard drive too, and put a copy of it in a bank vault somewhere... but I'm lazy. It might be cheaper to buy a second KoboAuraHD.

And before you say anything, the quality of the commit comment is on par with just about any place I've worked.

I think there's a Dilbert cartoon about that... eg: You must be in management, .... You must be in Engineering ... because ....

Yes, it would have been very good if their crystal ball had told them that they would need multiple versions of this and exactly what they would need to call them.

I'm probably ignorant about how the web browser interface works for git.

Is there no way to rename a directory after the fact, or show a history of what it was named (in the past) by clicking it somehow, or add a symlink directory once management had come up with a name for what engineering did, and decided to sell it on the market? I know second guessing management is impossible, but once they committed....!

I don't expect to change Kobo's middle of the road programming approach ; I'm just curious about the git interface as I'm not doing very well with it in the school of hard knocks.

So I want to be sure and jsay for spending the time to get me up to speed on where most things are not stored by crushing my misconceptions. Especially since the labels aren't always very helpful. I always try and remember that "Organic" is part of the word "organization" -- it's all about how things grow. And sometimes that means the only one who remembers where something is, is someone who has already been there for a long time. I appreciate it.

[tshering]

Originally Posted by frostschutz

The program that Kobo provides (pickel showpic) breaks that rule completely, it just rotates the screen and then nickel can't draw anymore until you manually restore the original rotation.

Are you sure about that? A test that some users did for me suggested that pickel changes the rotation only on Glo HD. Nickel however changes the rotation on all models except Touch, Mini and Glo. (On Glo HD, nickel seems to change the rotation only, if pickel has not already done so. I am not sure about that.) I guess your results differ because you start testing after nickel has already changed the rotation.

[frostschutz]

Sample program:

int query_rotate()
{
    int r;
    FILE * f = fopen("/sys/class/graphics/fb0/rotate", "r");
    r = fgetc(f)-'0';
    fclose(f);
    return r;
}

for(i=5; i--; )
{
    ioctl(fb0, FBIOGET_VSCREENINFO, &screen);
    printf("FBIOGET_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());

    ioctl(fb0, FBIOPUT_VSCREENINFO, &screen);
    printf("FBIOPUT_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());
}

(the query_rotate to verify what /sys/class/graphics/fb0/rotate reports is identical to what the ioctl reports, that seems to be the case)

Session on the H2O:

# reboot to get clean initial state
...
# ./flipper
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
# cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
# cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
# ./flipper
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOGET_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOGET_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)

So somehow writing to /sys/class/graphics/fb0/rotate "dirties" it and from then on it starts flipping the rotation around and suddenly you FBIOGET sometimes 1 sometimes 3 and you start drawing things upside down. So on one and same device you get two separate possible behaviours: it might flip the rotation or it might not. Confusing!

As a result, if you use FBIOPUT_VSCREENINFO, you have to use it twice in order to make sure the rotation is what you intended.

for(i=5; i--; )
{
    ioctl(fb0, FBIOGET_VSCREENINFO, &screen);
    printf("FBIOGET_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());

    ioctl(fb0, FBIOPUT_VSCREENINFO, &screen);
    printf("FBIOPUT_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());
    // doubled the FBIOPUT
    ioctl(fb0, FBIOPUT_VSCREENINFO, &screen);
    printf("FBIOPUT_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());
}

# reboot
...
# ./doubleflipper
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
# cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
# cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
# ./doubleflipper
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 3 (3)
FBIOPUT_VSCREENINFO 1 (1)

In this case dirty or not, GET always gets 1 and not either 1 or 3 as before.

That's not what pickel does, however. It calls get twice, put once.

ioctl(3, FBIOGET_VSCREENINFO, 0x7efb9820) = 0
ioctl(3, FBIOPUT_VSCREENINFO, 0x7efb9820) = 0
ioctl(3, FBIOGET_VSCREENINFO, 0x7efb9820) = 0

Also the flipper starts flipping after pickel even if the state was clean before.

# reboot
...
# ./doubleflipper
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
# /usr/local/Kobo/pickel showpic < /dev/urandom
# ./doubleflipper
FBIOGET_VSCREENINFO 2 (2)
FBIOPUT_VSCREENINFO 0 (0)
FBIOPUT_VSCREENINFO 2 (2)

(It's 2 now because pickel rotated the screen)

Since pickel is used during boot already, it's unclear to me how nickel afterwards starts out in a "clean" state and how using pickel again makes it start flipping using just FBIOGET/PUT when my own program using the same syscalls does not have the same effect.

It probably puts something into the vscreeninfo struct, but what? Or it just can handle either case on its own? What am I missing?

EDIT:

What I'm missing of course, is that pickel itself flips the rotation.

for(i=5; i--; )
{
    ioctl(fb0, FBIOGET_VSCREENINFO, &screen);
    printf("FBIOGET_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());

    screen.rotate^=0x2; // flip

    ioctl(fb0, FBIOPUT_VSCREENINFO, &screen);
    printf("FBIOPUT_VSCREENINFO %d (%d)\n", screen.rotate, query_rotate());
}

Apparently flipping the rotation does the dirtying (?) so before and after looks the same:

# reboot
...
# ./pngshow maze.png 
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
# cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
# cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
# ./pngshow maze.png 
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)
FBIOGET_VSCREENINFO 1 (1)
FBIOPUT_VSCREENINFO 1 (1)

That doesn't help me much though. I wanted to be able to know how to draw stuff correctly without ever touching the rotation, so that other running processes (nickel in particular) can still draw their own stuff without knowing the fb was modified in between.

This thing is giving me headaches.

Edit: I ended up with this framebuffer rotation hack for now:

// get rotation
ioctl(fb0, FBIOGET_VSCREENINFO, &screen);
// remember rotation
rotate = screen.rotate;
// flip rotation
screen.rotate ^= 0x2;
// put rotation: some devices flip on put, some don't
ioctl(fb0, FBIOPUT_VSCREENINFO, &screen);
// check if it did not flip
if(rotate != screen.rotate)
{
    // restore original rotation
    screen.rotate = rotate;
    // put original rotation
    ioctl(fb0, FBIOPUT_VSCREENINFO, &screen);
    // flip rotation
    screen.rotate ^= 0x2;
}
// now screen.rotate means the same thing on all devices
// regardless whether they flip or not

It's racy so better to do this once and remember.

[davidfor]

Originally Posted by fastrobot

I haven't checked all executables though I did chmod busybox, to make it suid root.
eg: Login, passwd, etc. won't work unless it's suid root.
I'm not concerned -- I just didn't want to say "full" upgrade, when it didn't wipe absolutely everything out on the partition and replace it.

The KoboRoot.tgz is just unpacked to "/". That will replace the file, and I'm pretty sure it won't change the permissions and ownership. Or, t might depend on the command used both to pack and unpack.

I'm also noticing that the values sent to the Kobo Glo for frontlight illumination start much higher in the Glo than on the Aura. Considering it's the same MSP430 driving the frontlight, that makes me wonder if replacing the Glo's lighting table with the Aura's would allow me to dim the screen more. I'll have to experiment with that later when I'm not pressed for time.

But, it might be the actual LEDs or something else in the circuit. For the Glo, there is a hardware mod to solder a resister in the right place that drops the light level.

Overall, it doesn't really look like KOBO has updated the kernels since the devices were released ; It's more of a test, once it's working and in production -- keep it that way....

Except that the kernels have changed. They have changed sizes every three or four times. That might be a change in the build, but, I'm pretty sure that Kobo have said there were changes that needed the matching kernel change.

OK. Although it's not impossible to do a dd in general, the way Kobo wrote the script is perhaps not intelligent enough to detect by an 'if' statement which partition it is running from and behave accordingly -- but OK, it's more important to understand what they did than what they could have done.

Well, I think it is most important to make it as failsafe as possible. And it seems to be. You have to work fairly hard to prevent a factory reset from working.

Yep. DId that... cloned to my hard drive. Probably should back up the hard drive too, and put a copy of it in a bank vault somewhere... but I'm lazy. It might be cheaper to buy a second KoboAuraHD.

Don't worry to much, as others have taken the images and they are available.

I think there's a Dilbert cartoon about that... eg: You must be in management, .... You must be in Engineering ... because ....

Hmm, I'm just trying to decide if I've been insulted or not

I'm probably ignorant about how the web browser interface works for git.

Is there no way to rename a directory after the fact, or show a history of what it was named (in the past) by clicking it somehow, or add a symlink directory once management had come up with a name for what engineering did, and decided to sell it on the market? I know second guessing management is impossible, but once they committed....!

I don't know. My git use is pretty basic. It probably can be done from the command line or one of the more sophisticated GUIs.

[frostschutz]

Originally Posted by davidfor

I'm pretty sure it won't change the permissions and ownership.

It does change permissions and ownerships of the files according to what's in the tar. Technically all tar should have root as owner and group but so far I've been too lazy to add the necessary --owner --group options to tar.

In practice it makes no difference. Everything on the Kobo runs as root anyway, and root does not care about wrong owners. So the only thing that really matters is the executable flag needed for binaries/scripts.

Of course, if you DO set the suid flag and the owner is wrong, then it really bites you as suddenly you execute stuff as nobody instead of root. Here suid causes problems instead of solving them.

suid on busybox is a bad idea. It would suid _everything_, not just passwd. So nobodies can overwrite files etc. etc. etc.

EDIT: I was wrong about busybox+suid, apparently busybox can handle it. Thanks @fastrobot for pointing that out to me you learn something new every day

[davidfor]

Originally Posted by frostschutz

It does change permissions and ownerships of the files according to what's in the tar. Technically all tar should have root as owner and group but so far I've been too lazy to add the necessary --owner --group options to tar.

Your right, tar should be handling it. But, I had something like this a while ago. Maybe it was zip, or the permissions of the user I was logged in as.

In practice it makes no difference. Everything on the Kobo runs as root anyway, and root does not care about wrong owners. So the only thing that really matters is the executable flag needed for binaries/scripts.

Of course, if you DO set the suid flag and the owner is wrong, then it really bites you as suddenly you execute stuff as nobody instead of root. Here suid causes problems instead of solving them.

suid on busybox is a bad idea. It would suid _everything_, not just passwd. So nobodies can overwrite files etc. etc. etc.

And yes, that sounds right.

[fastrobot]

Originally Posted by embryo

Did you already read about the "preventfreeze" hack that the KSM is using for the freezes of Glo?
Its difficult to find you the exact post (using my phone), but it was from the first things that tsering had to do for it to work on the Glo.

No, I haven't seen that.

I just compiled my dummy keyboard kernel module against the kernel in the repository labeled "Kobo Glo", and it gave me the exact same md5 sum as when I compiled it against the kernel for the KoboAuraHD. So it's not a problem with how I compiled it -- and therefore a hack like you are describing is exactly the kind of thing I'm needing to find.



Found it...:

Originally Posted by tshering

The content of preventfreeze.sh is

while :
do
  sleep 1
done

Do not forget to use a Unix-style editor.

So the problem description he has is the same as the one I have, a Glo which when left idle too long suddenly freezes up. Yep. Glad to know I'm not the only one experiencing this!

So -- Tschering's solution -- prevent-freeze is just a script which never enters blocking mode for more than one second. I see, that means the linux kernel is constantly being woken up and should never 'decide' that it is totally idle because all processes have entered blocking mode for a long time.

That's easy enough to try by running the script in the background, and seems likely to solve the problem in a roundabout way.

I'll go over and see my kids later today, and check if it works for them.
If it does, then I can move on to the next stage -- compiling frobtads, and zork, and hithikers guide to the galaxy eg: interactive fiction (choose your own ending book) games to run on the kobo.

Thank you very much!

[Ken Maltby]

Originally Posted by fastrobot

I'll go over and see my kids later today, and check if it works for them.
If it does, then I can move on to the next stage -- compiling frobtads, and zork, and hithikers guide to the galaxy eg: interactive fiction (choose your own ending book) games to run on the kobo.

Thank you very much!

The interactive games run on my Aura HD, using "Frotz", in Sergey's VlasosoftLauncher. This thread might help.

Luck;
Ken

[fastrobot]

Originally Posted by Ken Maltby

The interactive games run on my Aura HD, using "Frotz", in Sergey's VlasosoftLauncher. This thread might help.

Luck;
Ken

Doh! I just got Frobtads and Frotz working before I saw that. But Thanks.


I have a vitual terminal now, runing ncurses. So Frotz ran perfectly on the first try.
I simply downloaded the source code, compiled it with kobo's arm GCC, linked against my libraries; and installed it on an external SD card. Walah, instant play.

My terminal has a vitual morse code keyboard; so I just use tap out international morse code on the screen, and the letters magically appear about as fast as I can peck...

The only requirement (beyond having a terminal program) was to set up busybox to allow it to run as a regular user rather than superuser. Frotz won't run in superuser mode.

Let the Zork sword glow again...

I am curious, though; there's a QT based interactive fiction game engine called QTads,
and also that engine comes with a web server version since 3.1.
SInce the Kobo natively runs QT anyway, and also has a web browser, I would have thought that was an ideal fit.

Has anyone ported QTads to KOBO yet?

[fastrobot]

Originally Posted by frostschutz

So somehow writing to /sys/class/graphics/fb0/rotate "dirties" it and from then on it starts flipping the rotation around and suddenly you FBIOGET sometimes 1 sometimes 3 and you start drawing things upside down. So on one and same device you get two separate possible behaviours: it might flip the rotation or it might not. Confusing!

I don't even want to know the conversations that must have gone on behind the scenes the accept a kernel driver that did this in the first place and make pickel and nickel work around it rather than make a simple driver with highly predictable results.

What a waste of CPU power... reinitializing chips repetitively....because of redundant variables....

As a result, if you use FBIOPUT_VSCREENINFO, you have to use it twice in order to make sure the rotation is what you intended.

That's one solution.
The race conditions are the main problem.

In my own code (not shown), nickel and pickel are actually -SIGSTOPped, and the dummy zforce-ir-touch driver is disconnected by the virtual keyboard emulator; So it's not accumulating buffer data and clogging up.

So thats how I avoid race conditions as much as possible.
When I restore the buffer, I send nickel and hindenburg -SIGCONT.
So I could actually use your "write twice" solution without fear of race conditions with nickel, and I could add pickel to my killall list for extra security.

I probably ought to look up linux signal processing to make sure there's no race conditions possible, but in practice it's not been a problem. Even if it sits idle for a long time, nothing happens until -SIGCONT, and then the system immediately goes to sleep.
So unless it's coincidence, I think other signals / messages might queue up.
But Nickel appears to continue to run stably as far as I can tell. [ Note, the Glo Freezeup is happening when Nickel is running, so don't jump to wrong conclusions. And I have finally got an inkling of an idea of what might have caused it... and it has nothing to do with the code in this thread. ]

I don't see why you couldn't do the same thing, for if you are only writing to the buffer for a brief period of time; Your doing a brief -SIGSTOP is not likely to bother nickel or pickel's activities nearly as much as my long term interruptions do.

Of course, writing to the same screen that nickel is using is risky in it's own right, because there's nothing stopping nickel from reading that data and wanting to use it again -- assuming that the images it wrote there earlier are still valid. Not that I fully understand what you are doing, but it sounds riskier than what I want to do which is a total save, disable nickel and hindenburg, allow another application to run for a while, and then do a total restore and re-enable of nickel and hindenburg.

eg: I'm wanting to do the same as classic job control for a terminal, to allow two or more processes to share a screen.

Each application has it's own rotation, which may be the same or different. I just want to remember it during the save and restore operations, because the screen is not symmetrical and so rotating data already on a screen on the fly is impractical. It would change the drawings scale factor....

Three ideas come to mind from your analysis:

1) Nickel and Pickel already expect the weird behavior, so fixing the driver (assuming the behavior actually is broken) may not be an option as that could break Nickel and Pickel.
2) Pickel reads the buffer twice in a row before writing once; That's normally a useless operation unless the data in some variable changes from one read to the next. So pickel might be detecting a buffer rotation mode by comparing a variable we're not inspecting, and deciding to flip based on that. You might want to do a memcpy, and memcmp from one read to the next, and not read the /sys directory at the same time, to see if any variable changed during double reads. (It could also be stupid code.)
3) The actual "pseudo-random" flipping of the screen appears to be happening during the write operation, and in the write code of the kernel driver; because it's actually modifying the data structure of the write ioctl. So -- that narrows down the portion of the driver code to look at, and hope against hope there are some comments in the source code that make sense out of this unexpected extra rotation activity...

[fastrobot]

Now that I'm thinking about it....

I don't recall seeing a setting that allows me to rotate my book sideways, and read it in landscape mode rather than in portrait mode on the KoboAuraHD. Is there a setting for that? and where is it? (I have a manual, but it would take hours to find it....)

[davidfor]

Don't bother looking in the manual, there isn't an option. You can rotate PDF and images, but not epub or kepub.

[frostschutz]

Originally Posted by fastrobot

But Nickel appears to continue to run stably as far as I can tell.

nickel crashes randomly for me if I stop it at the wrong time. It could also be to input events accumulating as you said, not sure. I do use the stop/cont in my AutoShelf mod which stops it as you unplug it from USB. This seems to work fine and you can modify the database at this point.

Originally Posted by fastrobot

Of course, writing to the same screen that nickel is using is risky in it's own right, because there's nothing stopping nickel from reading that data and wanting to use it again

I don't think nickel reads the framebuffer data back for anything. So for example the dictionary that overlays part of the text, when it is removed it does not draw what was before in the framebuffer but it actually redraws the missing text itself. It's a partial redraw though, so if you damage a region that nickel still believes to be intact, you won't see nickel auto-repairing it - until you do something that causes nickel to redraw fully like flip the entire page.

Originally Posted by fastrobot

Not that I fully understand what you are doing
Each application has it's own rotation

I draw to the screen without having to change rotation first. I.e. have an application that does not have its own rotation but just uses what is there.

That way you can do full screen drawing without having to worry about restore. And you can also do partial screen drawing like a popup window or just adding a clock in a screen corner or things like that.

[tshering]

Originally Posted by frostschutz

The program that Kobo provides (pickel showpic) breaks that rule completely, it just rotates the screen and then nickel can't draw anymore until you manually restore the original rotation.

Originally Posted by tshering

Are you sure about that? A test that some users did for me suggested that pickel changes the rotation only on Glo HD. Nickel however changes the rotation on all models except Touch, Mini and Glo. (On Glo HD, nickel seems to change the rotation only, if pickel has not already done so. I am not sure about that.) I guess your results differ because you start testing after nickel has already changed the rotation.Are you sure about that? A test that some users did for me suggested that pickel changes the rotation only on Glo HD. Nickel however changes the rotation on all models except Touch, Mini and Glo. (On Glo HD, nickel seems to change the rotation only, if pickel has not already done so. I am not sure about that.) I guess your results differ because you start testing after nickel has already changed the rotation.

It does not contribute to the original question of the thread, but I feel I should modify what I have said. I generalized my observations to much. I should have said that in that test pickel changed the rotation only on Glo HD. The important part is that in that test a KSM application had already set the rotation value, and on all tested models except Glo HD, pickel uses the same rotation value as KSM. That is why I saw pickel changing the rotation only on Glo HD.

[fastrobot]

Originally Posted by frostschutz

Of course, if you DO set the suid flag and the owner is wrong, then it really bites you as suddenly you execute stuff as nobody instead of root. Here suid causes problems instead of solving them.

And busybox can bite you in more than one way....
But yes, if you don't make it suid root, then it suddenly causes problems instead of solving them. That's why I made it suid root:

chown root:root /bin/busybox
chmod +s /bin/busybox

It is in fact bizarre that kobo readers have several files which belong to a user id number which is not even in the /etc/passwd file, eg: essentially nobodies rather than root.

suid on busybox is a bad idea. It would suid _everything_, not just passwd. So nobodies can overwrite files etc. etc. etc.

Right now the kobo runs all software as root, as you yourself note.
So, If I just hand my kids the vt52 terminal directly after a framebuffer switch to the virtual terminal (the whole purpose of this thread ), by default the shell will come up with uid set to the process that called it; eg: uid = root, and path= /. So -- if my kids do something sily like rm -rf *, the whole Kobo gets destroyed, but even if they are careful game programs like frotz do not run because they test and refuse to run if logged in as root.

On the other hand, if I use a special command I created, eg: session to log them in as a non root user without busybox; I can't possibly get back to being root user from the terminal or do sudo commands to start wifi, etc. with -- Unless I can login as root from a non-root account.

But logging in as root requires busybox to be suid root.

It's messy, but in order to flexibly hack on the system without risking too much damage to the Kobo I really needed the ability to login as root (run su from non-root terminal) and log back out again to plain user, and have directories that are relatively safe for experimentation.

So: I partitioned an external SD card into three parts using fdisk. Partition one is an of type 0x0b, msdos vfat. It's a mere 2 megabytes, and contains only an autorun.sh script, and a handful of binaries that are nearly always in use -- such as bash, vt52u (the terminal), the morse code virtual keyboard driver. etc. Highly used and high risk scripts.
eg: Things that I don't want to have to 'kill' in order to unmount a partition, or remount it as readonly.

This has two desired effects, the Kobo sees an msdos partition and so nickel/hindenburg doesn't complain continually about the sd card being unreadable and needing to be formatted.
And it gives me a place to put executables which the kobo will auto-mount read-only root ownership for booting my auxilliary system.

But because msdos does not support unix permissions, like suid, without globally setting them for all files as part of the mountpoint permssions -- I made two other partitions.

The second partition is another msdos partion (type 0x0b) called 'home', which is the default login directory for a non-super user account that I add to the kobo. It is again resistant to corruption due to msdos's nature under hardware resets, so is a good place to put experimental files and game save files.

I made it a partition, rather than a subdirectory in the first partition -- because vfat doesn't support unix ownership and I don't want to fight kobo's default actions in mounting /mnt/sd. So: The first partition the Kobo mounts however it wants, (superuser ownership readonly), but the second partion mounts rw and is owned by user 'home'. (I made its mount point /mnt/home).

And of course, the third partition I created is a ext2fs partition (type 0x83); I call it user, and I made it ext2 because that's the only generic unix fs that the kobo supports natively.

And I mount that partition read only on a directory I create called /mnt/user.

If I need to edit files on the user partition, I mount it rw, make the changes, and then remount it read only. Since my sysadmin tools run from the first dos partition -- this means I can either unmount or remount user as rw, without worrying about the partition being 'busy' on a perpetual basis. All programs on that partition can be terminated without killing my user terminal or admin programs.

So I put binaries like python-2.7.10, frotz, frobtads,sorry,battleship, etc. in that third partition.

And remount it readonly before trying to execute them -- so if the system crashes, and is rebooted, I don't have a corrupted ext2fs filesystem on my hands without an ext2fsck program available....

As a note for you:

Busybox itself allows choosing which programs run with suid permissions and which ones don't when it's owned by root. (By default busybox exits suid root before running it's internal applets unless instructed not to -- even if the suid bit is set on busybox as far as I know -- but I'm no expert...).

There is is a configuration file that you can add in /etc which will tell busybox when to reset the suid permission to a the originating uid (non superuser id) and when not to reset it -- all you need to do is create an extra configuration file in /etc called (drumroll) busybox.conf
Mine is like this:

[SUID]
su = ssx root.root
login = ssx root.root

and do:
chown root:root /etc/busybox.conf
chmod 600 /etc/busybox.conf

That's it -- the Kobo is happy to oblige multi users with those changes, and will only allow two busybox programs to run setuser id -- the rest must run as the id of the person calling busybox.

I thought about not making the kobo's busybox suid, and instead putting a copy busybox on a mounted external filesystem, but having two copies of busybox sort of defeats the memory management benefits of having all tools in a single image; for linux can share code memory images among many different instances of runnning busybox commands if it comes from the same file -- but not if from multiple files.

Hardlinks, unfortuantely, don't support different permissions on linux; so we can't make busybox suid under one name, and not suid under another.
Softlinks don't allow suid changes either.
(By the way, I just partially bricked my reader experimenting with that again and I even knew better! --- *sigh* time to drag out the sd card reader again or do factory reset ... )


And although I can make the group permission sgid on busybox, but leave the owner permission as non-suid; I don't see how that would help. For I am not sure how a non-root user to could change to a new group without having an suid busybox in the first place.

It's sort of crazy that kobo has a busybox that is default user:group 501:1000 , which are not defined anywhere in /etc. Sloppy programming. But that's the way it is.

So -- the only alternative to changing the mode of busybox to suid root, that I see -- it to create a standalone setiud root program on my third partition, eg: a sudo program that is not part of busybox.

I'm pretty happy with the way busybox works when suid root is set for allowing a 'regular' user account, so I think I'm going to just keep using it; but the kobo does have one really irritating security feature which I think might be part of busybox, for it refuses to export LD_LIBRARY_PATH during the 'env' command execution, so that a user who wishes to make an autorun python script in the 'home' partition can't put '#!/user/bin/env python' at the start of the python script, because the kobo's version of ENV erases the system variable called LD_LIBRARY_PATH.

That prevents security breaches by replacing shared libraries with hacked ones, but it also prevents me from running pyhon in an autoscript as a regular user.

I suppose I could do "#!/usr/bin/env LD_LIBRARY_PATH=/mnt/user/lib python"
as the first line, but it seems that there ought to be a better way to do it that is less system dependent...



EDIT: Nope, even that solution causes the program to hang totally.
Apparently env can't handle people setting environment variables as part of a script start execution...
It works from the command line, but not as a script auto-start command.

EDIT: OOOOOH! Check this out
Almost every unix out there puts a shell of some kind on /bin/sh. The system shell....
Busybox is no exception:

SO, watch this shell game -played over telnet exclusively on the AuraHD -- closely ---:

~ # echo $LD_LIBRARY_PATH
/mnt/user/lib
~ # export LD_LIBARY_PATH="/mnt/user/lib"
~ # login home
Password: 
[home@AndrewsKoboHD ~]$ echo $LD_LIBRARY_PATH
/mnt/user/lib
[home@AndrewsKoboHD ~]$ export LD_LIBRARY_PATH="/mnt/user/lib"
[home@AndrewsKoboHD ~]$ /bin/sh -c "python"
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
[home@AndrewsKoboHD ~]$ /bin/sh -c "LD_LIBRARY_PATH=$LD_LIBRARY_PATH python"
Python 2.7.10 (default, Jun 30 2015, 20:30:05) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

If I set LD_LIBRARY path to itself, it works.
Busybox, a program named after a toy meant to entertain infants uselessly for hours... Good thing I don't actually have to have this program running by tomorrow...!

~ # login
AndrewsKoboHD login: home      
Password: 
[home@AndrewsKoboHD ~]$ echo $LD_LIBRARY_PATH
/mnt/user/lib
[home@AndrewsKoboHD ~]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
[home@AndrewsKoboHD ~]$ sh
[home@AndrewsKoboHD ~]$ echo $LD_LIBARY_PATH

[home@AndrewsKoboHD ~]$ 
[home@AndrewsKoboHD ~]$ exit
[home@AndrewsKoboHD ~]$ echo $LD_LIBRARY_PATH
/mnt/user/lib 
[home@AndrewsKoboHD ~]$ export quote="YES"
[home@AndrewsKoboHD ~]$ bash
[home@AndrewsKoboHD ~]$ echo $quote
YES
[home@AndrewsKoboHD ~]$ exit
[home@AndrewsKoboHD ~]$ exit
~ # echo $LD_LIBRARY_PATH
/mnt/user/lib
~ # export quote="yup"
~ # sh
~ # echo $quote
yup
~ # bash
bash-4.3# echo $quote
yup
bash-4.3# sh
~ #echo $quote
yup

Wow. So, in which shell is the LD_LIBRARY_PATH NOT found? Pick a shell, any shell...