| 07:40:56 | skanda | anybody has any idea where exactly should the PH bit be cleared in the memory Setup |
| 07:42:51 | skanda | the PH bit in the PSSR |
| 10:08:03 | seletz | hi filks! |
| 10:08:07 | seletz | erm. |
| 10:08:10 | seletz | hi folks! |
| 10:08:14 | seletz | :) |
| 10:09:10 | Russ | morning erikm |
| 10:09:12 | erikm | hi seletz |
| 10:09:15 | erikm | and Russ |
| 10:09:27 | Sammy | hello seletz |
| 10:09:31 | Sammy | and erikm |
| 10:09:32 | Russ | http://russ.dhs.org/files/tuxpatches/backlight-2.4.15-pre6-rmk1 |
| 10:09:39 | Russ | http://russ.dhs.org/files/tuxpatches/backlight_test.c |
| 10:09:56 | Russ | moved it to fbmem.c |
| 10:10:03 | Russ | lost my nifty pm hooks though |
| 10:10:19 | erikm | fires up netscape |
| 10:11:31 | erikm | russ.dhs.org: Host not found. |
| 10:11:56 | seletz | works for me ... |
| 10:11:59 | Russ | http://russ.dhcp.asu.edu/files/tuxpatches/backlight-2.4.15-pre6-rmk1 |
| 10:12:10 | Russ | http://russ.dhcp.asu.edu/files/tuxpatches/backlight_test.c |
| 10:14:11 | seletz | Russ: how do you get those jffs2 images so tiny? :) |
| 10:14:41 | Russ | uclibc, they are old images though |
| 10:15:05 | seletz | Russ: ulibc worth the effort at all, then? |
| 10:15:49 | Russ | uclibc is very good, but no C++ support, and minimal pthread support |
| 10:16:15 | seletz | ugh. i need c++. |
| 10:16:49 | Russ | its something that can be added |
| 10:16:58 | Russ | just no one has had time |
| 10:17:06 | seletz | hmm, well. :) |
| 10:17:17 | erikm | uhm, writing a C++ library is not trivial |
| 10:17:17 | Russ | what do you need c++ for? |
| 10:17:43 | seletz | does not need c++. But our GUI will be in QT/embedded. |
| 10:17:52 | erikm | aieee |
| 10:17:56 | Russ | the main part that is aparantly missing is the arm loader |
| 10:20:22 | erikm | Russ: looks good |
| 10:21:17 | erikm | Russ: looks quite simple, actually |
| 10:21:55 | erikm | Russ: you could put the pm callbacks in shannon_backlight.c |
| 10:21:59 | Russ | erikm: do you think there should be ioctl's to set values individualy? |
| 10:22:41 | Russ | erikm: the point is to keep shannon_backlight.c very simple, because there will be such a module for every board |
| 10:23:05 | erikm | Russ: I don't think so. it's all physical display properties |
| 10:23:20 | erikm | Russ: so a single ioctl should do |
| 10:23:45 | Russ | I mean, right now, it reads power, brightness, contrast all at once, and sets them all at once |
| 10:24:09 | Russ | if one app tries to set power, and another brightness, there can be a race |
| 10:24:19 | Russ | and one app doesn't get to do what it wants |
| 10:24:29 | erikm | hmm |
| 10:26:49 | erikm | that might be a problem, yes |
| 10:27:39 | Russ | also, I thought I might break out the changing of values in fbmem.c into an individual function, that could be called safely from anywhere |
| 10:27:42 | erikm | seletz: I don't know if rmk already told you, but diffs to the patch system should be unified diffs, not context diffs |
| 10:28:13 | seletz | Russ: looking erikm: yes, rmk told me, the patch system told me and i know now :) |
| 10:28:27 | Russ | and instead of having power/brightness/contrast, it would be an array of 3 settings, so the function could just be called with a enum or define, instead of if contrast/brightness, etc |
| 10:28:32 | seletz | (garbled input line) |
| 10:28:51 | Russ | seletz: were you the one who sumbmitted the system3 stuff? |
| 10:29:01 | seletz | erm. yes? |
| 10:29:37 | Russ | heh |
| 10:29:37 | seletz | Russ: yes, im the one to blame :) |
| 10:30:20 | Russ | how hard would it be to make a system3_backlight.c, like the shannon_backlight.c in the above patch? |
| 10:30:54 | seletz | Russ: one moment, i'll have a look ... |
| 10:31:06 | seletz | d/l files |
| 10:31:54 | erikm | Russ: you mean making functions fb_set_brightness(), fb_set_contrast(), etc? |
| 10:32:27 | Russ | right |
| 10:32:48 | Russ | well |
| 10:32:52 | erikm | Russ: well, it would certainly be according to the linux coding standards :) |
| 10:32:59 | Russ | system3_brightness, system3_contrast, etc |
| 10:33:08 | Russ | oh, wait, you are a little up |
| 10:33:19 | erikm | yes, I was in fbmem.c |
| 10:33:50 | Russ | erikm: actually, fb_backlight_set_value(backlight, type, value) |
| 10:34:03 | erikm | ewww |
| 10:34:26 | erikm | Russ: functions that need type parameters are frowned upon in the kernel |
| 10:34:27 | Russ | well, then, if I put the different setable values in some sort of array, I don't need to make special cases for each |
| 10:35:41 | erikm | Russ: hmm, but if you use it as an index to an array, it might make sense |
| 10:35:58 | erikm | Russ: difficult case :) |
| 10:36:09 | Russ | right now, I go through each case for power, contrast, and backlight |
| 10:36:22 | Russ | and if I broke those out into functions, I'd be doing locking in each |
| 10:36:45 | seletz | ok, as i see it this is quite above some hw stuff, there are some mutexes around this stuff. I just wanted to write a driver for this sort of things. And no, it would be no problem to add such things. actually there is a system3_lcd:contrast(value) function. |
| 10:37:02 | Russ | seletz: I protect your module |
| 10:37:09 | Russ | seletz: you don't need to worry about any re-entry |
| 10:38:09 | seletz | Russ: yes, we wanted to have some sort of system-control driver, where some userland proc can do some ioctl()s to control various things. |
| 10:38:22 | Russ | brb, drp |
| 10:38:25 | seletz | Russ: backlight, contrast etc. |
| 10:39:10 | seletz | translate( brp ) = ? |
| 10:41:24 | Russ | drp = dr pepper |
| 10:42:28 | Russ | seletz: right |
| 10:42:48 | Russ | seletz: and the system-control driver is completely board independant |
| 10:43:04 | Russ | seletz: drivers for different boards can register with it |
| 10:43:07 | seletz | Russ: as i understood this up to now, should'nt this be handled by /dev/fb0 already? |
| 10:43:21 | erikm | seletz: no, it doesn't. |
| 10:43:39 | erikm | seletz: /dev/fb0 assumes that the framebuffer is just a framebuffer |
| 10:43:50 | Russ | probably would add a backlights directory to driver/video to handle the resulting clutter |
| 10:43:59 | erikm | seletz: it doesn't know that you can also directly control the hardware with it |
| 10:44:07 | erikm | s/hardware/screen/ |
| 10:44:22 | seletz | Russ: ah. ok, but registering callbacks woud be nice. Probably with different services. |
| 10:44:42 | seletz | Russ: a /proc interface would be nice, too. |
| 10:45:10 | seletz | Russ: so one can test this things with some shell. |
| 10:45:24 | Russ | seletz: maybe later, wouldn't be hard to add later, right now, I have a small test app |
| 10:45:56 | erikm | seletz: not really. we don't want to clutter /proc |
| 10:46:23 | seletz | erikm: hmm, then maybe via the sysctl() feature? |
| 10:46:34 | Russ | seletz: there is already a ioctl |
| 10:46:53 | Russ | too bad /proc/fb isn't a directory |
| 10:47:14 | seletz | Russ: well, lets make it one :) |
| 10:47:24 | erikm | expect to see a lot of /proc crap go away in linux-2.5 |
| 10:47:45 | Russ | seletz: if it gets standardized, fbutils would have a app for it |
| 10:47:51 | seletz | hmmm. what exactly is the definition of crap in this context :) |
| 10:48:18 | seletz | Russ: right so. |
| 10:48:18 | Russ | meminfo? |
| 10:48:22 | erikm | seletz: everything not process related |
| 10:48:47 | erikm | seletz: like /proc/filesystems, for example |
| 10:49:08 | seletz | erikm: i always thought /proc as a great way to have an easy interface to drivers. |
| 10:49:20 | seletz | erikm: from shell scripts for ex. |
| 10:49:36 | erikm | seletz: it is, but most things could been done with normal device nodes as well |
| 10:50:43 | Russ | seletz: seems like its doing the jobs of little user space utilities in the kernel |
| 10:50:50 | seletz | erikm: _silly question_: are dev nrs 16 bit in 2.5? |
| 10:51:27 | erikm | seletz: I expect them to go 32 bit |
| 10:51:48 | erikm | seletz: but that *will* break quite a lot of stuff, so how that is going to happen is not yet clear |
| 10:52:34 | seletz | erikm: well, then i'll have to change my mind i suppose. I counted strongly on the /proc interface up to now. Sigh. |
| 10:53:33 | seletz | Russ: this driver you wrote looks quite ready to go, does it? |
| 10:54:14 | erikm | seletz: the difference between 2.2 and 2.4 wasn't too large. I expect that the difference between 2.4 and 2.6 will be that large that we'll directly go to 3.0 |
| 10:54:43 | Russ | seletz: want to work out the details before I submit ti |
| 10:54:44 | Russ | er, it |
| 10:54:53 | Russ | and probably tie it in a bit with pm again |
| 10:55:29 | seletz | Russ: np. |
| 10:56:00 | erikm | Russ: you might want to integrate patch 700/1 directly |
| 10:56:04 | seletz | Russ: i also saw your ir keyboard patch. have some goot place to look at for understanding ps/2? |
| 10:56:12 | seletz | s/goot/good/ |
| 10:56:22 | erikm | seletz: the linux-console project |
| 10:56:34 | erikm | seletz: (also on sourceforge) |
| 10:56:40 | Russ | seletz: its more or less a serial keyboard |
| 10:57:17 | Russ | eww...patch 700 |
| 10:57:21 | Russ | have you looked at that thing? |
| 10:57:32 | erikm | Russ: I skimmed over it |
| 10:57:44 | seletz | erikm: well they seem not yet in a shape that will go into the kernel, do they? The event interface idea i like very much, tough. |
| 10:57:45 | Russ | if(!machine_is_freebird()) |
| 10:58:05 | Russ | its horrid |
| 10:58:24 | erikm | Russ: but if you get the assabet mechanism out of it, you could show how easy it is to make a machine dependent driver |
| 10:58:37 | Russ | the freebird/assabet stuff needs to be pulled apart |
| 10:59:40 | erikm | Russ: ditch the freebird stuff, only go for the assabet |
| 11:00:20 | Russ | a lot of sleeping can be involved |
| 11:00:24 | Russ | but thats probably ok |
| 11:01:21 | Russ | right now, if one process is sleeping or running in kernel for its ioctl, and another process attempts an ioctl, it returns -EBUSY |
| 11:01:26 | Russ | should I have it sleep instead |
| 11:01:27 | Russ | ? |
| 11:02:13 | erikm | ioctl on the same device, you mean? |
| 11:02:31 | Russ | the ioctl to set backlight values |
| 11:03:04 | Russ | right though, on the same device |
| 11:03:18 | erikm | that would be quite normal |
| 11:03:41 | Russ | kinda sucks to handle in userspace though, since you can't sleep on it |
| 11:04:52 | erikm | Russ: why not? just put the process to sleep |
| 11:05:02 | erikm | Russ: see linux device drivers 2nd edition |
| 11:05:15 | Russ | shouldn't be too hard to do? |
| 11:07:01 | erikm | not really. we used to have interruptible_sleep_on() for that, but that's racy. the current wisdom is to use set_current_state(TASK_INTERRUPTIBLE); schedule(); |
| 11:08:16 | erikm | lots of drivers have these two lines of code |
| 11:09:06 | erikm | (or schedule_timeout() instead of schedule()) |
| 11:09:27 | erikm | oops, SIGLUNCH |
| 11:24:20 | seletz | got thrown out, now im back in .... |
| 11:38:25 | erikm | re |
| 13:45:27 | seletz | Russ: are you here? |
| 13:47:04 | Russ | ya |
| 13:47:33 | seletz | Russ: i talked to you about ordering a tuxscreen, yes? |
| 13:47:53 | Russ | no, you would want to talk to BZFlag |
| 13:48:41 | seletz | Russ: ugh, yes, now i remember. sorry for bugging. |
| 13:48:59 | | BZFlag was last seen on #bzflag 4 hours, 35 minutes and 2 seconds ago, saying: base pos is part of world, not a separate msg. [Tue Nov 20 09:13:57 2001] |
| 13:48:59 | seletz | ibot: seen BZFlag? |
| 13:55:48 | seletz | help |
| 13:55:56 | seletz | sorry wrong window |
| 15:19:33 | seletz | zp |
| 19:15:35 | Russ | geez, hh.org submitted a lot of patches |
| 19:15:51 | erikm | jup |
| 19:15:56 | erikm | looks at them |
| 19:16:06 | erikm | though _rmk_ was also going to do that |
| 19:16:46 | Russ | one would hope |
| 19:17:42 | erikm | _rmk_ has some problems with his adsl connection today |
| 19:18:41 | Russ | hey lookie, a h3x00 frontlight driver |
| 19:19:11 | erikm | he'll drop that :) |
| 19:19:22 | Russ | well, its stuck into another driver |
| 19:19:29 | Russ | the HAL thing |
| 19:20:11 | erikm | a HAL? wtf... |
| 19:20:38 | Russ | 787 |
| 19:21:48 | erikm | we'll need your backlight patch asap |
| 19:22:11 | erikm | I gave _rmk_ the url of the patch, I don't know if he got it |
| 19:22:31 | erikm | (due to hist adsl problems today) |
| 19:23:20 | Russ | don't think its done yet, its still kind of kludgy on the ioctl side |
| 19:23:37 | Russ | I'll have time to work on it today though |
| 19:24:28 | erikm | I'll see if I can get rmk to visit #blob or #tuxscreen today |
| 19:32:55 | erikm | Russ: I don't see why we need 787/1. the kernel *is* the HAL. no need to make yet another HAL. |
| 19:33:52 | Russ | I think its the best term they could find for what they are doing |
| 19:33:56 | Russ | look at the next patch |
| 19:34:15 | Russ | runs lindent on sa1100_frontlight.c |
| 19:50:59 | Russ | hmm...assabet_frontlight.c is very simple |
| 19:54:08 | erikm | your rewrite of it, you mean? |
| 19:55:43 | Russ | ya |
| 19:55:50 | Russ | since assabet only has power on/power off |
| 19:56:21 | Russ | freebird is a little strange though |