9 Apr
2010
9 Apr
'10
3:35 p.m.
Hi,
I converted the X font 5x8 for use in BB and added an goto_xy
routine in case anyone wants to put something entertaining on
the LCD (besides Hello World).
Compared to the old 8x8 font..
- doesn't miss the topmost line of pixels :-)
- needs 475 bytes instead of 4k (only includes characters
ASCII 32 .. 126)
- allows for 19x8 characters on the screen
hello_world.bin prints out all glyphs for testing.
Applies to current "master" (as of 9.4.2010/15:30 MESZ).
Chris
10 Apr
10 Apr
9:26 a.m.
Hi Christian,
first of all thanks for your patch.
I think it is great to have a better/smaller font. However,
I cannot merge the patch as-is, as I have the following comments:
1) we need a way to select between individual fonts when writing
to the display. I think in the long run it is inevitable that
we'll use small and big letters on screen and have to select/
switch between them.
Something like display_select_font(FONT_5x8) to be called
before a display_puts() sounds like a reasonable API for this.
2) Removing all the special characters might not be the best idea to do.
If at all, it should be a compile time option whether or not to drop
the special characters.
Also, the check for replacing a character with '?' needs to be
a font-specific and not a global decision.
3) introducing the new font should be one patch, fixing the 'miss
topmost line' another patch, and any experimental changes to
hello_world/main.c should be yet another patch. This way we
can keep the commitlog a bit more clean.
I hope you're willing to rework your code, thanks in advance!
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:46 p.m.
Hi Harald,
thanks for your comments. I'll address them below.
On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte <laforge(a)gnumonks.org>
wrote:
1) we need a way to select between individual fonts
when writing
to the display. I think in the long run it is inevitable that
we'll use small and big letters on screen and have to select/
switch between them.
Something like display_select_font(FONT_5x8) to be called
before a display_puts() sounds like a reasonable API for this.
I completely agree. The motivation for my (first) patch was mainly to
have *something* on the screen (e.g. serial port Rx/Tx bytes, whatever)
and that needs just a usable font and gotoxy. I never considered it
a final UI library.
But if we want to do it proper, I have a few question to you and the list:
- If we stick to multiple-of-8-high fonts (at least on the C128) we
can just blindly write at the proper location. The C155 (?) might
have different restrictions. Is this ok or should we try to support
arbitrary sized fonts?
- If we want to support arbitrary sized fonts, we either should buffer
the display in RAM (might be wasteful on high res color displays?)
or read/modify/write over i2c (might be slow, occupy the bus for too
long). What's your opinion on that?
- Which font-encoding should we use? I know that GSM 03.38 specifies
the encoding used for SMSs, but should we stick with that for
on-screen output? It's not ASCII compatible regarding []{}\...
Note:
<steve|m> in IRC told me that prom is probably already working on that?
Is he reading the list? prom, can you confirm?
2) Removing all the special characters might not be
the best idea to do.
If at all, it should be a compile time option whether or not to drop
the special characters.
Also, the check for replacing a character with '?' needs to be
a font-specific and not a global decision.
I agree, see also 3rd tick-mark above.
3) introducing the new font should be one patch,
fixing the 'miss
topmost line' another patch, and any experimental changes to
hello_world/main.c should be yet another patch. This way we
can keep the commitlog a bit more clean.
OK, I agree with that. Btw: fixing the topmost line in the 8x8 font
will have to be done by whoever contributed the 8x8 font in the first
place :-)
Greetings from Bavaria,
Chris
11 Apr
11 Apr
7:48 a.m.
Hi Christian,
On Sat, Apr 10, 2010 at 05:46:48PM +0300, Christian Vogel wrote:
But if we want to do it proper, I have a few question
to you and the list:
- If we stick to multiple-of-8-high fonts (at least on the C128) we
can just blindly write at the proper location. The C155 (?) might
have different restrictions. Is this ok or should we try to support
arbitrary sized fonts?
we need arbitrary sized fonts :(
- If we want to support arbitrary sized fonts, we
either should buffer
the display in RAM (might be wasteful on high res color displays?)
or read/modify/write over i2c (might be slow, occupy the bus for too
long). What's your opinion on that?
yes, we need a memory frame buffer that is periodically synchronized (if
any changes have happened) to the real device by means of a low-priority
task.
- Which font-encoding should we use? I know that GSM
03.38 specifies
the encoding used for SMSs, but should we stick with that for
on-screen output? It's not ASCII compatible regarding []{}\...
I think we should use ASCII for screen output despite what the GSM
standard alphabet does. libosmocore already has conversion functions I
believe.
Note:
<steve|m> in IRC told me that prom is probably already working on that?
Is he reading the list? prom, can you confirm?
He's reading the list and the plan was to commit his unfinished code to
a branch in the repository.
OK, I agree with that. Btw: fixing the topmost line in
the 8x8 font
will have to be done by whoever contributed the 8x8 font in the
first place :-)
ah, ok, that would be me. I still have the perl script somewhwere that
was used to generate the code.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
11 May
11 May
1:01 p.m.
New subject: Greetings
Hi Folks.
I only wanted to let you know that i am still alive ;-) I am currently
very busy with my industrial practical so i have not much time at all but...
Currently i am implementing an easy to use API to the basic simcard
functions. After that i will build an API on top of this that handles
the sim requests in an atomic way to make it easy to give other
processes random access to the sim through a message queue.
regards.
Philipp
2:58 p.m.
New subject: Greetings
Hi dexter,
Someone (IIRC, <kevredon(a)mail.tsaitgaist.info> ) suggested to implement the
SIM access profile. Do you know that? Is it a generic protocol we could
implement over the serial line (to access the real sim in the phone) and/or
a function call interface (to access a sim through PCSC) ?
Regards
Sebastien
On Tue, May 11, 2010 at 1:01 PM, dexter <zero-kelvin(a)gmx.de> wrote:
Hi Folks.
I only wanted to let you know that i am still alive ;-) I am currently very
busy with my industrial practical so i have not much time at all but...
Currently i am implementing an easy to use API to the basic simcard
functions. After that i will build an API on top of this that handles the
sim requests in an atomic way to make it easy to give other processes random
access to the sim through a message queue.
regards.
Philipp
13 May
13 May
5:10 p.m.
New subject: Greetings
Hello Sébastien.
Someone (IIRC, <kevredon(a)mail.tsaitgaist.info
<mailto:kevredon@mail.tsaitgaist.info>> ) suggested to implement the
SIM access profile. Do you know that? Is it a generic protocol we
could implement over the serial line (to access the real sim in the
phone) and/or a function call interface (to access a sim through PCSC) ?
Why? I
don't see any advantages in this and i do not have the know how
to implement SIM access profile. I think it is enough if we have our own
simple simcard API that works for us. We should not overengineer this.
Regards.
Philipp
6:28 p.m.
New subject: Greetings
Hello,
I have to say that I agree with you. I was just reporting the idea I heard
about :-)
Regards
Sebastien
On Thu, May 13, 2010 at 5:10 PM, dexter <zero-kelvin(a)gmx.de> wrote:
Hello Sébastien.
Someone (IIRC, <kevredon(a)mail.tsaitgaist.info
<mailto:
kevredon(a)mail.tsaitgaist.info>> ) suggested to implement the SIM access
profile. Do you know that? Is it a generic protocol we could implement over
the serial line (to access the real sim in the phone) and/or a function call
interface (to access a sim through PCSC) ?
Why? I don't see any advantages in this and i do not have the know how to
implement SIM access profile. I think it is enough if we have our own simple
simcard API that works for us. We should not overengineer this.
Regards.
Philipp
6:36 p.m.
New subject: Greetings
dexter wrote:
There's at least one significant advantage; it becomes trivial and
convenient to use a real SIM in another phone on your desk.
suggested to
implement the SIM access profile.
Why? I don't see any advantages in this
and i do not have the know how to implement SIM access
profile.
There was a link to the (pretty short) spec in the email thread.
I think it is enough if we have our own simple simcard
API that
works for us. We should not overengineer this.
At least I think the SIM access profile is a good idea. I haven't
looked into detail, but maybe it's actually similar to the simple
API?
//Peter
14 May
14 May
5:19 a.m.
New subject: Greetings
On Thu, 13 May 2010 18:36:31 +0200
Peter Stuge <peter(a)stuge.se> wrote:
dexter wrote:
>> suggested to implement the SIM access profile.
> Why? I don't see any advantages in this
Did you have a look at the spec?
http://nibbler.de/attic/bluetooth/profile%20SAP%20v1.1.pdf
See page 23 and 32.
It basically implements a minimalistic remote card reader that
forwards APDUs to and from the SIM. All the lower level protocols have
already been implemented e.g. in the Linux kernel.
While it might indeed be not a thing to implement first, it still looks
worth keeping it in mind and interfaces open for a later integration of
SAP as a convenient way to access SIMs remotely.
cheers,
nibbler
p.s. don't spread the link as i don't know exactly about the copyright
implications of all the bluetooth documents in that folder. I happened
to have an account for the SIG document repository thus found it handy
to mirror the specification documents which to my knowledge are not
publicly available.
9:08 a.m.
New subject: Greetings
Hi,
Well after seeing the spec, the protocol does not seem too over engineered.
These are just messages in byte buffers that can be exchanged over any link,
be it bluetooth, serial or struct{} in a function call.
So instead of reinventing a wheel that will look like this, why not
implement a simplified version of this spec? we only have to implement
the messages required for our needs.
Regards
Sebastien
On Fri, May 14, 2010 at 5:19 AM, nibbler <nibbler(a)ccc.de> wrote:
On Thu, 13 May 2010 18:36:31 +0200
Peter Stuge <peter(a)stuge.se> wrote:
dexter wrote:
>> suggested to implement the SIM access profile.
> Why? I don't see any advantages in this
Did you have a look at the spec?
http://nibbler.de/attic/bluetooth/profile%20SAP%20v1.1.pdf
See page 23 and 32.
It basically implements a minimalistic remote card reader that
forwards APDUs to and from the SIM. All the lower level protocols have
already been implemented e.g. in the Linux kernel.
While it might indeed be not a thing to implement first, it still looks
worth keeping it in mind and interfaces open for a later integration of
SAP as a convenient way to access SIMs remotely.
cheers,
nibbler
p.s. don't spread the link as i don't know exactly about the copyright
implications of all the bluetooth documents in that folder. I happened
to have an account for the SIG document repository thus found it handy
to mirror the specification documents which to my knowledge are not
publicly available.
10:17 a.m.
New subject: Greetings
Hi All.
So instead of reinventing a wheel that will look like
this, why not
implement a simplified version of this spec? we only have to implement
the messages required for our needs.
I think that does not help us much. We need a layer that abstracts the
SIM functions to atomic high level functions so that different processes
can access the sim randomly (This is not my idea that was haralds idea ;-)
As i can see the SAP is hooked to the low level APDU interface. Is there
any way to arbitrate the requests? What is when someone from outside
selects a file while the mobile already has selected a file and is about
to do a read binary for example?
Anyway. I have not the time to read and understand the entire SAP spec.
If you think that SAP works better for us you are free to continue the
work instead of me. I will then concentrate on the SIM driver itsselef -
there is much work left to do there and the low level stuff is more that
what i am experienced with.
Currently we have an APDU interface to the sim. You can send APDUs to
the sim and you get the answer and status word back. T=0 protocol is
fully implemented.
regards.
Philipp
5098
days inactive
5133
days old
baseband-devel@lists.osmocom.org
11 comments
6 participants
participants (6)
-
Christian Vogel -
dexter -
Harald Welte -
nibbler -
Peter Stuge -
Sébastien Lorquet