Re: Some questions

Re: Some questions

[Никита Горбунов]

I write my ioengine and have some questions about how work fio.

1. What to do if function "getevents" transmitted pointer (const
struct timespec *t) which indicated garbage?
I want to paused my ioengine on some msec(sec,nsec) when ioengine
wants get answer about recording of write. I don't understand how can
get time for waiting if time pointer indicated garbage. Why does he
pass the pointer to the garbage?
2. What is the call queue function of ioengine? Can you write minimal
viable call chain? (init->open->queue->commit->getevents->cleanup)

3. Are the function of ioengine can be called in several threads
without indicated numjobs?

4. Why in null-ioengine when iodepth=1 we indicate this flag:
"td->io_ops->flags |= FIO_SYNCIO;" (sorry for my english)

(sorry for my english)

Re: Some questions

[Sitsofe Wheeler]

Hi,

On 4 October 2017 at 07:58, Никита Горбунов <tshiva@promobit.ru> wrote:
> I write my ioengine and have some questions about how work fio.
>
> 1. What to do if function "getevents" transmitted pointer (const
> struct timespec *t) which indicated garbage?
> I want to paused my ioengine on some msec(sec,nsec) when ioengine
> wants get answer about recording of write. I don't understand how can
> get time for waiting if time pointer indicated garbage. Why does he
> pass the pointer to the garbage?

You need to check if it is not null before you use it. Off the top of
my head I think this is the only place I've seen it being used
https://github.com/axboe/fio/blob/fio-3.1/engines/libaio.c#L145 and
it's only usuable in certain conditions. If you chase your way up the
code to https://github.com/axboe/fio/blob/fio-3.1/io_u.c#L2001 you can
see you only get a non-NULL timespec when you don't require a minimum
number of events before returning (i.e. the case where you're using
the libaio ioengine with userspace_reap=1 - see
http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-userspace-reap
). If you need to just wait for an amount of time you can grab/check
time with fio_gettime/mtime_since_now as in
https://github.com/axboe/fio/blob/fio-3.1/engines/libaio.c#L284 .

> 2. What is the call queue function of ioengine? Can you write minimal
> viable call chain? (init->open->queue->commit->getevents->cleanup)

It's going to depend. The comments in the skeleton ioengine
(https://github.com/axboe/fio/blob/fio-3.1/engines/skeleton_external.c
actually state which callbacks must be present (e.g. commit is
optional because your ioengine might be synchrnous). Even open/close
may not be required if the ioengine is somehow synthetic or
connectionless. There are also additional optional callbacks that can
be added that are not mentioned in the skeleton ioengine...

Your suggested chain looks OK if all those are callbacks are defined
but you may find queue is called multiple times successively (since it
seems your theoretical ioengine is async), getevents may be called
multiple times etc.

> 3. Are the function of ioengine can be called in several threads
> without indicated numjobs?

Each numjob gets its own ioengine - you don't know if a job is going
to be run as a process or a thread. If your ioengine is using
something that's not thread safe then your ioengine is responsible for
serializing access to it...

> 4. Why in null-ioengine when iodepth=1 we indicate this flag:
> "td->io_ops->flags |= FIO_SYNCIO;" (sorry for my english)

(I think this setting is informal enough you don't need to worry too
much about your English so long as people know what you mean :-) That
ioengine "wants" to behave like a synchronous ioengine when the depth
is 1 and like an asynchronous ioengine when the depth is greater than
1. I'm guessing wildly but perhaps being an asynchronous ioengine
induces a bit of extra overhead? If you're writing a "throw everything
away" ioengine that is going as fast as possible for benchmarking the
other parts of fio itself, every little counts...

-- 
Sitsofe | http://sucs.org/~sits/

Re: Some questions

[Paul E. McKenney]

On Sat, Apr 30, 2016 at 07:06:39AM +0900, Akira Yokosawa wrote:
> On 2016/04/30 2:15, Paul E. McKenney wrote:
> > On Sat, Apr 30, 2016 at 01:00:29AM +0900, Akira Yokosawa wrote:
> >> On 2016/04/29 8:05, Akira Yokosawa wrote:
> >>> On 2016/04/29 1:28, Paul E. McKenney wrote:
> >>>> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
> >>>>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> >>>>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> >>>>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> >>>>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >>>>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> >>>>> [snip.
> >>>>>>>>>> Please see attached for what it looks like to me.
> >>>>>>>>>
> >>>>>>>>> Well, this is identical to the one I built.
> >>>>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
> >>>>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
> >>>>>>>>
> >>>>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
> >>>>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
> >>>>>>>> actually completing a read.
> >>>>>>>
> >>>>>>> Oh, I see. But this should be explained in the text, I think.
> >>>>>>
> >>>>>> Good point!  I also added several other possibilities, including
> >>>>>> interrupts and preemption.
> >>>>>>
> >>>>>
> >>>>> So, I have a few questions regarding to the added explanation of blank cells.
> >>>>>
> >>>>> According to the text, trace data used to create the table are said to be 
> >>>>> obtained by a program that contains the code fragment shown in Figure 14.4.
> >>>>> The loop in the code fragment will exit once it sees state.variable != mycpu.
> >>>>> That means the actual program you used has an outer loop to record the
> >>>>> changes of state.valuable for each cpu in the system, I suppose.
> >>>>> Am I guessing right?
> >>>>
> >>>> IIRC, the program just stuffed timestamps and values into a set of per-CPU
> >>>> big arrays, then printed them out.  A script took these values as input,
> >>>> and compacted identical state.
> >>>>
> >>>>> If I am, (n)'s in the table denoting modification of variables must be
> >>>>> entries in the trace data which were output from the outer loop, I think.
> >>>>
> >>>> The (n)'s mark changes in value for a given CPU.
> >>>>
> >>>>> However, in the table, there are a number of cases where (n)'s are followed
> >>>>> by blanks just below itself. Does this mean fetched state.variables stay in
> >>>>> the cache very briefly, but are (almost immediately) invalidated by a cache
> >>>>> coherence mechanism? I can see interrupts and preemption would also cause the
> >>>>> trace output to be suspended for a while.
> >>>>
> >>>> It marks places where a given CPU saw a value momentarily.  As you say,
> >>>> this could be due to cache invalidation, interrupts, preemption, etc.
> >>>>
> >>>>> I'm not sure I have made out what the table means thus far, but am I seeing
> >>>>> something close enough to what you intend the table to represent?
> >>>>
> >>>> The main point is that different CPUs can disagree on the value of a given
> >>>> variable at a given point in time.  The following diagram shows that
> >>>> this disagreement is nevertheless bounded, in that all CPUs must agree
> >>>> on the ordering of values for that variable.
> >>>
> >>> Yes, of course that's the main point.
> >>> I should have asked in a different way.
> >>>
> >>> There should be the same kind of situations in Figure 14.5.
> >>> But you didn't depict them in the figure.
> >>>
> >>> Why did you put the blank cells in the table in the first place?
> >>>
> >>> I'm a little bit distracted by those blank cells, and began questioning
> >>> about them.
> >>>
> >>> Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
> >>>
> >>> Or, could the blank cell situation be explained in the form of an answer
> >>> of a quick quiz?  It would be much easier for me to grasp the main point
> >>> of this section "Variables Can Have More Than One Value" while reading the
> >>> body of the text.
> >>>
> >>> Thoughts?
> >>>
> >>>                                                    Thanks, Akira
> >>>
> >>>>
> >>>> 							Thanx, Paul
> >>>>
> >>>>
> >>>
> >>
> >> So I drew 2 figures based on Table 14.2.
> >> No, I didn't actually drew them but wrote a rough program to generate .fig
> >> format files from the value changes of each CPU extracted from Table 14.2.
> >> I ignored the blank cells in the table just as in Figure 4.5.
> >> Appended is a tar ball of two files.
> >> out.fig is the overall diagram, and out-2.fig is a zoomed in view of
> >> the beginning part.
> >> I think they can provide a fairly interesting view of what's going on.
> >>
> >> Please give a look at them.
> > 
> > Not bad, actually!
> > 
> > The solid black areas need to be hatched or grey, otherwise it is a bit
> > hard on printers.  The colored areas look OK to me, though that does
> > not necessarily count for much.  ;-)
> 
> I'll see what I can.
> 
> > 
> > Would you like to send a patch replacing the table with these diagrams
> > and updating the text appropriately?
> 
> I'd love to!
> And may I remove the explanation of the "white cell situation" for now?
> Or do you want to keep those info in another set of diagrams which would
> depict the unresponsive periods in some way (translucent hatch or something)
> so that you could refer to them in a quick quiz you might come up with
> some day? 

I could add a quick quiz to the effect of "What about cache-miss latency?"

Let's start with the simple diagram and see how it looks.

							Thanx, Paul

Re: Some questions

[Akira Yokosawa]

On 2016/04/30 2:15, Paul E. McKenney wrote:
> On Sat, Apr 30, 2016 at 01:00:29AM +0900, Akira Yokosawa wrote:
>> On 2016/04/29 8:05, Akira Yokosawa wrote:
>>> On 2016/04/29 1:28, Paul E. McKenney wrote:
>>>> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
>>>>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
>>>>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>>>>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>>>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>>>>> [snip.
>>>>>>>>>> Please see attached for what it looks like to me.
>>>>>>>>>
>>>>>>>>> Well, this is identical to the one I built.
>>>>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>>>>>>
>>>>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>>>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>>>>>>> actually completing a read.
>>>>>>>
>>>>>>> Oh, I see. But this should be explained in the text, I think.
>>>>>>
>>>>>> Good point!  I also added several other possibilities, including
>>>>>> interrupts and preemption.
>>>>>>
>>>>>
>>>>> So, I have a few questions regarding to the added explanation of blank cells.
>>>>>
>>>>> According to the text, trace data used to create the table are said to be 
>>>>> obtained by a program that contains the code fragment shown in Figure 14.4.
>>>>> The loop in the code fragment will exit once it sees state.variable != mycpu.
>>>>> That means the actual program you used has an outer loop to record the
>>>>> changes of state.valuable for each cpu in the system, I suppose.
>>>>> Am I guessing right?
>>>>
>>>> IIRC, the program just stuffed timestamps and values into a set of per-CPU
>>>> big arrays, then printed them out.  A script took these values as input,
>>>> and compacted identical state.
>>>>
>>>>> If I am, (n)'s in the table denoting modification of variables must be
>>>>> entries in the trace data which were output from the outer loop, I think.
>>>>
>>>> The (n)'s mark changes in value for a given CPU.
>>>>
>>>>> However, in the table, there are a number of cases where (n)'s are followed
>>>>> by blanks just below itself. Does this mean fetched state.variables stay in
>>>>> the cache very briefly, but are (almost immediately) invalidated by a cache
>>>>> coherence mechanism? I can see interrupts and preemption would also cause the
>>>>> trace output to be suspended for a while.
>>>>
>>>> It marks places where a given CPU saw a value momentarily.  As you say,
>>>> this could be due to cache invalidation, interrupts, preemption, etc.
>>>>
>>>>> I'm not sure I have made out what the table means thus far, but am I seeing
>>>>> something close enough to what you intend the table to represent?
>>>>
>>>> The main point is that different CPUs can disagree on the value of a given
>>>> variable at a given point in time.  The following diagram shows that
>>>> this disagreement is nevertheless bounded, in that all CPUs must agree
>>>> on the ordering of values for that variable.
>>>
>>> Yes, of course that's the main point.
>>> I should have asked in a different way.
>>>
>>> There should be the same kind of situations in Figure 14.5.
>>> But you didn't depict them in the figure.
>>>
>>> Why did you put the blank cells in the table in the first place?
>>>
>>> I'm a little bit distracted by those blank cells, and began questioning
>>> about them.
>>>
>>> Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
>>>
>>> Or, could the blank cell situation be explained in the form of an answer
>>> of a quick quiz?  It would be much easier for me to grasp the main point
>>> of this section "Variables Can Have More Than One Value" while reading the
>>> body of the text.
>>>
>>> Thoughts?
>>>
>>>                                                    Thanks, Akira
>>>
>>>>
>>>> 							Thanx, Paul
>>>>
>>>>
>>>
>>
>> So I drew 2 figures based on Table 14.2.
>> No, I didn't actually drew them but wrote a rough program to generate .fig
>> format files from the value changes of each CPU extracted from Table 14.2.
>> I ignored the blank cells in the table just as in Figure 4.5.
>> Appended is a tar ball of two files.
>> out.fig is the overall diagram, and out-2.fig is a zoomed in view of
>> the beginning part.
>> I think they can provide a fairly interesting view of what's going on.
>>
>> Please give a look at them.
> 
> Not bad, actually!
> 
> The solid black areas need to be hatched or grey, otherwise it is a bit
> hard on printers.  The colored areas look OK to me, though that does
> not necessarily count for much.  ;-)

I'll see what I can.

> 
> Would you like to send a patch replacing the table with these diagrams
> and updating the text appropriately?

I'd love to!
And may I remove the explanation of the "white cell situation" for now?
Or do you want to keep those info in another set of diagrams which would
depict the unresponsive periods in some way (translucent hatch or something)
so that you could refer to them in a quick quiz you might come up with
some day? 

                                                  Thanks, Akira
> 
> 						Thanx, Paul
> 
> 

Re: Some questions

[Paul E. McKenney]

On Sat, Apr 30, 2016 at 01:00:29AM +0900, Akira Yokosawa wrote:
> On 2016/04/29 8:05, Akira Yokosawa wrote:
> > On 2016/04/29 1:28, Paul E. McKenney wrote:
> >> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
> >>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> >>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> >>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> >>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> >>> [snip.
> >>>>>>>> Please see attached for what it looks like to me.
> >>>>>>>
> >>>>>>> Well, this is identical to the one I built.
> >>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
> >>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
> >>>>>>
> >>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
> >>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
> >>>>>> actually completing a read.
> >>>>>
> >>>>> Oh, I see. But this should be explained in the text, I think.
> >>>>
> >>>> Good point!  I also added several other possibilities, including
> >>>> interrupts and preemption.
> >>>>
> >>>
> >>> So, I have a few questions regarding to the added explanation of blank cells.
> >>>
> >>> According to the text, trace data used to create the table are said to be 
> >>> obtained by a program that contains the code fragment shown in Figure 14.4.
> >>> The loop in the code fragment will exit once it sees state.variable != mycpu.
> >>> That means the actual program you used has an outer loop to record the
> >>> changes of state.valuable for each cpu in the system, I suppose.
> >>> Am I guessing right?
> >>
> >> IIRC, the program just stuffed timestamps and values into a set of per-CPU
> >> big arrays, then printed them out.  A script took these values as input,
> >> and compacted identical state.
> >>
> >>> If I am, (n)'s in the table denoting modification of variables must be
> >>> entries in the trace data which were output from the outer loop, I think.
> >>
> >> The (n)'s mark changes in value for a given CPU.
> >>
> >>> However, in the table, there are a number of cases where (n)'s are followed
> >>> by blanks just below itself. Does this mean fetched state.variables stay in
> >>> the cache very briefly, but are (almost immediately) invalidated by a cache
> >>> coherence mechanism? I can see interrupts and preemption would also cause the
> >>> trace output to be suspended for a while.
> >>
> >> It marks places where a given CPU saw a value momentarily.  As you say,
> >> this could be due to cache invalidation, interrupts, preemption, etc.
> >>
> >>> I'm not sure I have made out what the table means thus far, but am I seeing
> >>> something close enough to what you intend the table to represent?
> >>
> >> The main point is that different CPUs can disagree on the value of a given
> >> variable at a given point in time.  The following diagram shows that
> >> this disagreement is nevertheless bounded, in that all CPUs must agree
> >> on the ordering of values for that variable.
> > 
> > Yes, of course that's the main point.
> > I should have asked in a different way.
> > 
> > There should be the same kind of situations in Figure 14.5.
> > But you didn't depict them in the figure.
> > 
> > Why did you put the blank cells in the table in the first place?
> > 
> > I'm a little bit distracted by those blank cells, and began questioning
> > about them.
> > 
> > Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
> > 
> > Or, could the blank cell situation be explained in the form of an answer
> > of a quick quiz?  It would be much easier for me to grasp the main point
> > of this section "Variables Can Have More Than One Value" while reading the
> > body of the text.
> > 
> > Thoughts?
> > 
> >                                                    Thanks, Akira
> > 
> >>
> >> 							Thanx, Paul
> >>
> >>
> > 
> 
> So I drew 2 figures based on Table 14.2.
> No, I didn't actually drew them but wrote a rough program to generate .fig
> format files from the value changes of each CPU extracted from Table 14.2.
> I ignored the blank cells in the table just as in Figure 4.5.
> Appended is a tar ball of two files.
> out.fig is the overall diagram, and out-2.fig is a zoomed in view of
> the beginning part.
> I think they can provide a fairly interesting view of what's going on.
> 
> Please give a look at them.

Not bad, actually!

The solid black areas need to be hatched or grey, otherwise it is a bit
hard on printers.  The colored areas look OK to me, though that does
not necessarily count for much.  ;-)

Would you like to send a patch replacing the table with these diagrams
and updating the text appropriately?

						Thanx, Paul

Re: Some questions

[Akira Yokosawa]

[-- Attachment #1: Type: text/plain, Size: 4367 bytes --]

On 2016/04/29 8:05, Akira Yokosawa wrote:
> On 2016/04/29 1:28, Paul E. McKenney wrote:
>> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
>>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
>>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>>> [snip.
>>>>>>>> Please see attached for what it looks like to me.
>>>>>>>
>>>>>>> Well, this is identical to the one I built.
>>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>>>>
>>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>>>>> actually completing a read.
>>>>>
>>>>> Oh, I see. But this should be explained in the text, I think.
>>>>
>>>> Good point!  I also added several other possibilities, including
>>>> interrupts and preemption.
>>>>
>>>
>>> So, I have a few questions regarding to the added explanation of blank cells.
>>>
>>> According to the text, trace data used to create the table are said to be 
>>> obtained by a program that contains the code fragment shown in Figure 14.4.
>>> The loop in the code fragment will exit once it sees state.variable != mycpu.
>>> That means the actual program you used has an outer loop to record the
>>> changes of state.valuable for each cpu in the system, I suppose.
>>> Am I guessing right?
>>
>> IIRC, the program just stuffed timestamps and values into a set of per-CPU
>> big arrays, then printed them out.  A script took these values as input,
>> and compacted identical state.
>>
>>> If I am, (n)'s in the table denoting modification of variables must be
>>> entries in the trace data which were output from the outer loop, I think.
>>
>> The (n)'s mark changes in value for a given CPU.
>>
>>> However, in the table, there are a number of cases where (n)'s are followed
>>> by blanks just below itself. Does this mean fetched state.variables stay in
>>> the cache very briefly, but are (almost immediately) invalidated by a cache
>>> coherence mechanism? I can see interrupts and preemption would also cause the
>>> trace output to be suspended for a while.
>>
>> It marks places where a given CPU saw a value momentarily.  As you say,
>> this could be due to cache invalidation, interrupts, preemption, etc.
>>
>>> I'm not sure I have made out what the table means thus far, but am I seeing
>>> something close enough to what you intend the table to represent?
>>
>> The main point is that different CPUs can disagree on the value of a given
>> variable at a given point in time.  The following diagram shows that
>> this disagreement is nevertheless bounded, in that all CPUs must agree
>> on the ordering of values for that variable.
> 
> Yes, of course that's the main point.
> I should have asked in a different way.
> 
> There should be the same kind of situations in Figure 14.5.
> But you didn't depict them in the figure.
> 
> Why did you put the blank cells in the table in the first place?
> 
> I'm a little bit distracted by those blank cells, and began questioning
> about them.
> 
> Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
> 
> Or, could the blank cell situation be explained in the form of an answer
> of a quick quiz?  It would be much easier for me to grasp the main point
> of this section "Variables Can Have More Than One Value" while reading the
> body of the text.
> 
> Thoughts?
> 
>                                                    Thanks, Akira
> 
>>
>> 							Thanx, Paul
>>
>>
> 

So I drew 2 figures based on Table 14.2.
No, I didn't actually drew them but wrote a rough program to generate .fig
format files from the value changes of each CPU extracted from Table 14.2.
I ignored the blank cells in the table just as in Figure 4.5.
Appended is a tar ball of two files.
out.fig is the overall diagram, and out-2.fig is a zoomed in view of
the beginning part.
I think they can provide a fairly interesting view of what's going on.

Please give a look at them.

                                                    Thanks, Akira

[-- Attachment #2: fig.tar.gz --]
[-- Type: application/gzip, Size: 2368 bytes --]

Re: Some questions

[Akira Yokosawa]

On 2016/04/29 1:28, Paul E. McKenney wrote:
> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>> [snip.
>>>>>>> Please see attached for what it looks like to me.
>>>>>>
>>>>>> Well, this is identical to the one I built.
>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>>>
>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>>>> actually completing a read.
>>>>
>>>> Oh, I see. But this should be explained in the text, I think.
>>>
>>> Good point!  I also added several other possibilities, including
>>> interrupts and preemption.
>>>
>>
>> So, I have a few questions regarding to the added explanation of blank cells.
>>
>> According to the text, trace data used to create the table are said to be 
>> obtained by a program that contains the code fragment shown in Figure 14.4.
>> The loop in the code fragment will exit once it sees state.variable != mycpu.
>> That means the actual program you used has an outer loop to record the
>> changes of state.valuable for each cpu in the system, I suppose.
>> Am I guessing right?
> 
> IIRC, the program just stuffed timestamps and values into a set of per-CPU
> big arrays, then printed them out.  A script took these values as input,
> and compacted identical state.
> 
>> If I am, (n)'s in the table denoting modification of variables must be
>> entries in the trace data which were output from the outer loop, I think.
> 
> The (n)'s mark changes in value for a given CPU.
> 
>> However, in the table, there are a number of cases where (n)'s are followed
>> by blanks just below itself. Does this mean fetched state.variables stay in
>> the cache very briefly, but are (almost immediately) invalidated by a cache
>> coherence mechanism? I can see interrupts and preemption would also cause the
>> trace output to be suspended for a while.
> 
> It marks places where a given CPU saw a value momentarily.  As you say,
> this could be due to cache invalidation, interrupts, preemption, etc.
> 
>> I'm not sure I have made out what the table means thus far, but am I seeing
>> something close enough to what you intend the table to represent?
> 
> The main point is that different CPUs can disagree on the value of a given
> variable at a given point in time.  The following diagram shows that
> this disagreement is nevertheless bounded, in that all CPUs must agree
> on the ordering of values for that variable.

Yes, of course that's the main point.
I should have asked in a different way.

There should be the same kind of situations in Figure 14.5.
But you didn't depict them in the figure.

Why did you put the blank cells in the table in the first place?

I'm a little bit distracted by those blank cells, and began questioning
about them.

Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?

Or, could the blank cell situation be explained in the form of an answer
of a quick quiz?  It would be much easier for me to grasp the main point
of this section "Variables Can Have More Than One Value" while reading the
body of the text.

Thoughts?

                                                   Thanks, Akira

> 
> 							Thanx, Paul
> 
> 

Re: Some questions

[Paul E. McKenney]

On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> > On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> >> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> >>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> [snip.
> >>>>> Please see attached for what it looks like to me.
> >>>>
> >>>> Well, this is identical to the one I built.
> >>>> So, do you intend to explicitly put numbers which show up fairly long time, and
> >>>> leave other cells blank even below changes of values denoted by (n) in italics?
> >>>
> >>> The blank cells represent cache misses.  The CPU is waiting for a read
> >>> to complete during that time.  A non-blank cell corresponds to a CPU
> >>> actually completing a read.
> >>
> >> Oh, I see. But this should be explained in the text, I think.
> > 
> > Good point!  I also added several other possibilities, including
> > interrupts and preemption.
> > 
> 
> So, I have a few questions regarding to the added explanation of blank cells.
> 
> According to the text, trace data used to create the table are said to be 
> obtained by a program that contains the code fragment shown in Figure 14.4.
> The loop in the code fragment will exit once it sees state.variable != mycpu.
> That means the actual program you used has an outer loop to record the
> changes of state.valuable for each cpu in the system, I suppose.
> Am I guessing right?

IIRC, the program just stuffed timestamps and values into a set of per-CPU
big arrays, then printed them out.  A script took these values as input,
and compacted identical state.

> If I am, (n)'s in the table denoting modification of variables must be
> entries in the trace data which were output from the outer loop, I think.

The (n)'s mark changes in value for a given CPU.

> However, in the table, there are a number of cases where (n)'s are followed
> by blanks just below itself. Does this mean fetched state.variables stay in
> the cache very briefly, but are (almost immediately) invalidated by a cache
> coherence mechanism? I can see interrupts and preemption would also cause the
> trace output to be suspended for a while.

It marks places where a given CPU saw a value momentarily.  As you say,
this could be due to cache invalidation, interrupts, preemption, etc.

> I'm not sure I have made out what the table means thus far, but am I seeing
> something close enough to what you intend the table to represent?

The main point is that different CPUs can disagree on the value of a given
variable at a given point in time.  The following diagram shows that
this disagreement is nevertheless bounded, in that all CPUs must agree
on the ordering of values for that variable.

							Thanx, Paul

Re: Some questions

[Akira Yokosawa]

On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
[snip.
>>>>> Please see attached for what it looks like to me.
>>>>
>>>> Well, this is identical to the one I built.
>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>
>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>> actually completing a read.
>>
>> Oh, I see. But this should be explained in the text, I think.
> 
> Good point!  I also added several other possibilities, including
> interrupts and preemption.
> 

So, I have a few questions regarding to the added explanation of blank cells.

According to the text, trace data used to create the table are said to be 
obtained by a program that contains the code fragment shown in Figure 14.4.
The loop in the code fragment will exit once it sees state.variable != mycpu.
That means the actual program you used has an outer loop to record the
changes of state.valuable for each cpu in the system, I suppose.
Am I guessing right?

If I am, (n)'s in the table denoting modification of variables must be
entries in the trace data which were output from the outer loop, I think.

However, in the table, there are a number of cases where (n)'s are followed
by blanks just below itself. Does this mean fetched state.variables stay in
the cache very briefly, but are (almost immediately) invalidated by a cache
coherence mechanism? I can see interrupts and preemption would also cause the
trace output to be suspended for a while.

I'm not sure I have made out what the table means thus far, but am I seeing
something close enough to what you intend the table to represent?

                                                     Thanks, Akira

Re: Some questions

[Paul E. McKenney]

On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> > On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> >>> On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
> >>> [snip]
> >>>
> >>>> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
> >>>> seems like it is not complete yet.  Is that the case?
> >>>
> >>> Please see attached for what it looks like to me.
> >>
> >> Well, this is identical to the one I built.
> >> So, do you intend to explicitly put numbers which show up fairly long time, and
> >> leave other cells blank even below changes of values denoted by (n) in italics?
> > 
> > The blank cells represent cache misses.  The CPU is waiting for a read
> > to complete during that time.  A non-blank cell corresponds to a CPU
> > actually completing a read.
> 
> Oh, I see. But this should be explained in the text, I think.

Good point!  I also added several other possibilities, including
interrupts and preemption.

> >>>> Looks like you used some custom script or something to generate the table
> >>>> from a raw data that contains when each cpu sees the updates.
> >>>>
> >>>> Do you have a plan to replace the Table with a Figure something like
> >>>> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
> >>>
> >>> I briefly considered coloring the table cells, but got distracted.
> >>
> >> That kind of work would be made easy if you make a script or something to
> >> generate the latex source of the table. The problem is the script itself
> >> might take time to make it work properly. I could be of help in that area. 
> > 
> > I probably do have something somewhere...  No guarantees of finding it...
> > 
> >>> I am not sure that making a 14.5-like barchart would be all that
> >>> readable...  But please feel free to prove me wrong.
> >>
> >> There would be a number of very narrow bars hard to recognize.
> >> It would also be impossible to see there are fourteen different opinions
> >> at time 20. Yes, a table seems a better way to represent this.
> > 
> > Not sure that there is a really good way to represent this, but again,
> > please feel free to prove me wrong!  A nicer representation would be a
> > very good thing.
> > 
> > 							Thanx, Paul
> > 
> >>>> If you do, I'll refrain from touching the Table. Rather, I'd be interested
> >>>> in improving the script you might be using, if any.
> >>>>
> >>>> Another totally unrelated question is about the URL you placed in
> >>>> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
> >>>> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
> >>>> URL still accessible today?
> >>>
> >>> This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
> >>>
> >>>> By looking up a Wikipedia article, I found a page at
> >>>> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
> >>>> which is "Archived technical documentation library" of Alpha
> >>>> containing links to technical documentation for Alpha microprocessors
> >>>> and Alpha ATX motherboards. Is there a document there which can be
> >>>> referred to instead of the above mentioned URL?
> >>>
> >>> Ah, I see...  I blew it and included the URL verbatim in the text.
> >>> It should be replaced with \cite{Compaq01}.
> >>>
> >>> Fixed, with your Reported-by!  Thank you!
> >>
> >> Oh, you are most welcome!
> >>                                                    Thanks, Akira
> >>>
> >>> 							Thanx, Paul
> >>>
> >>
> 
> You might need to modify the repeated reference to the URL just before
> footnote 6 in Section C.7.1

Good catch!  I put the citation here as well.

							Thanx, Paul

Re: Some questions

[Akira Yokosawa]

On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>>> On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
>>> [snip]
>>>
>>>> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
>>>> seems like it is not complete yet.  Is that the case?
>>>
>>> Please see attached for what it looks like to me.
>>
>> Well, this is identical to the one I built.
>> So, do you intend to explicitly put numbers which show up fairly long time, and
>> leave other cells blank even below changes of values denoted by (n) in italics?
> 
> The blank cells represent cache misses.  The CPU is waiting for a read
> to complete during that time.  A non-blank cell corresponds to a CPU
> actually completing a read.

Oh, I see. But this should be explained in the text, I think.
> 
>>>> Looks like you used some custom script or something to generate the table
>>>> from a raw data that contains when each cpu sees the updates.
>>>>
>>>> Do you have a plan to replace the Table with a Figure something like
>>>> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
>>>
>>> I briefly considered coloring the table cells, but got distracted.
>>
>> That kind of work would be made easy if you make a script or something to
>> generate the latex source of the table. The problem is the script itself
>> might take time to make it work properly. I could be of help in that area. 
> 
> I probably do have something somewhere...  No guarantees of finding it...
> 
>>> I am not sure that making a 14.5-like barchart would be all that
>>> readable...  But please feel free to prove me wrong.
>>
>> There would be a number of very narrow bars hard to recognize.
>> It would also be impossible to see there are fourteen different opinions
>> at time 20. Yes, a table seems a better way to represent this.
> 
> Not sure that there is a really good way to represent this, but again,
> please feel free to prove me wrong!  A nicer representation would be a
> very good thing.
> 
> 							Thanx, Paul
> 
>>>> If you do, I'll refrain from touching the Table. Rather, I'd be interested
>>>> in improving the script you might be using, if any.
>>>>
>>>> Another totally unrelated question is about the URL you placed in
>>>> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
>>>> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
>>>> URL still accessible today?
>>>
>>> This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
>>>
>>>> By looking up a Wikipedia article, I found a page at
>>>> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
>>>> which is "Archived technical documentation library" of Alpha
>>>> containing links to technical documentation for Alpha microprocessors
>>>> and Alpha ATX motherboards. Is there a document there which can be
>>>> referred to instead of the above mentioned URL?
>>>
>>> Ah, I see...  I blew it and included the URL verbatim in the text.
>>> It should be replaced with \cite{Compaq01}.
>>>
>>> Fixed, with your Reported-by!  Thank you!
>>
>> Oh, you are most welcome!
>>                                                    Thanks, Akira
>>>
>>> 							Thanx, Paul
>>>
>>

You might need to modify the repeated reference to the URL just before
footnote 6 in Section C.7.1

                                               Thanks, Akira

Re: Some questions

[Paul E. McKenney]

On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> > On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
> > [snip]
> > 
> >> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
> >> seems like it is not complete yet.  Is that the case?
> > 
> > Please see attached for what it looks like to me.
> 
> Well, this is identical to the one I built.
> So, do you intend to explicitly put numbers which show up fairly long time, and
> leave other cells blank even below changes of values denoted by (n) in italics?

The blank cells represent cache misses.  The CPU is waiting for a read
to complete during that time.  A non-blank cell corresponds to a CPU
actually completing a read.

> >> Looks like you used some custom script or something to generate the table
> >> from a raw data that contains when each cpu sees the updates.
> >>
> >> Do you have a plan to replace the Table with a Figure something like
> >> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
> > 
> > I briefly considered coloring the table cells, but got distracted.
> 
> That kind of work would be made easy if you make a script or something to
> generate the latex source of the table. The problem is the script itself
> might take time to make it work properly. I could be of help in that area. 

I probably do have something somewhere...  No guarantees of finding it...

> > I am not sure that making a 14.5-like barchart would be all that
> > readable...  But please feel free to prove me wrong.
> 
> There would be a number of very narrow bars hard to recognize.
> It would also be impossible to see there are fourteen different opinions
> at time 20. Yes, a table seems a better way to represent this.

Not sure that there is a really good way to represent this, but again,
please feel free to prove me wrong!  A nicer representation would be a
very good thing.

							Thanx, Paul

> >> If you do, I'll refrain from touching the Table. Rather, I'd be interested
> >> in improving the script you might be using, if any.
> >>
> >> Another totally unrelated question is about the URL you placed in
> >> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
> >> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
> >> URL still accessible today?
> > 
> > This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
> > 
> >> By looking up a Wikipedia article, I found a page at
> >> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
> >> which is "Archived technical documentation library" of Alpha
> >> containing links to technical documentation for Alpha microprocessors
> >> and Alpha ATX motherboards. Is there a document there which can be
> >> referred to instead of the above mentioned URL?
> > 
> > Ah, I see...  I blew it and included the URL verbatim in the text.
> > It should be replaced with \cite{Compaq01}.
> > 
> > Fixed, with your Reported-by!  Thank you!
> 
> Oh, you are most welcome!
>                                                    Thanks, Akira
> > 
> > 							Thanx, Paul
> > 
> 

Re: Some questions

[Akira Yokosawa]

On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
> [snip]
> 
>> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
>> seems like it is not complete yet.  Is that the case?
> 
> Please see attached for what it looks like to me.

Well, this is identical to the one I built.
So, do you intend to explicitly put numbers which show up fairly long time, and
leave other cells blank even below changes of values denoted by (n) in italics?

> 
>> Looks like you used some custom script or something to generate the table
>> from a raw data that contains when each cpu sees the updates.
>>
>> Do you have a plan to replace the Table with a Figure something like
>> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
> 
> I briefly considered coloring the table cells, but got distracted.

That kind of work would be made easy if you make a script or something to
generate the latex source of the table. The problem is the script itself
might take time to make it work properly. I could be of help in that area. 

> 
> I am not sure that making a 14.5-like barchart would be all that
> readable...  But please feel free to prove me wrong.

There would be a number of very narrow bars hard to recognize.
It would also be impossible to see there are fourteen different opinions
at time 20. Yes, a table seems a better way to represent this.

> 
>> If you do, I'll refrain from touching the Table. Rather, I'd be interested
>> in improving the script you might be using, if any.
>>
>> Another totally unrelated question is about the URL you placed in
>> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
>> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
>> URL still accessible today?
> 
> This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
> 
>> By looking up a Wikipedia article, I found a page at
>> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
>> which is "Archived technical documentation library" of Alpha
>> containing links to technical documentation for Alpha microprocessors
>> and Alpha ATX motherboards. Is there a document there which can be
>> referred to instead of the above mentioned URL?
> 
> Ah, I see...  I blew it and included the URL verbatim in the text.
> It should be replaced with \cite{Compaq01}.
> 
> Fixed, with your Reported-by!  Thank you!

Oh, you are most welcome!
                                                   Thanks, Akira
> 
> 							Thanx, Paul
> 

Some questions

[Akira Yokosawa]

Hi, Paul.

The quotations recently added at the top of Chapters look really nice!
They make perfbook look more like a full-fledged publication.

However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
seems like it is not complete yet.  Is that the case?

Looks like you used some custom script or something to generate the table
from a raw data that contains when each cpu sees the updates.

Do you have a plan to replace the Table with a Figure something like
Figure 14.5 "A Variable With Multiple Simultaneous Values"?

If you do, I'll refrain from touching the Table. Rather, I'd be interested
in improving the script you might be using, if any.

Another totally unrelated question is about the URL you placed in
Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
Sadly, this URL is no longer valid. Do you happen to aware of an alternative
URL still accessible today?

By looking up a Wikipedia article, I found a page at
http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
which is "Archived technical documentation library" of Alpha
containing links to technical documentation for Alpha microprocessors
and Alpha ATX motherboards. Is there a document there which can be
referred to instead of the above mentioned URL?

                                                  Thanks, Akira

Some questions.

[Артём Алексюк]

Hello.
Sorry if I'm interrupting you with stupid questions :) I have a netbook with 
Atom N570 and GMA 3150.
1) I disabled KWin desktop effects for reducing power consumption. Is it a good 
solution or there is no difference if desktop effects are being switched on or 
switched off? How many extra watts (average, of course) will be used if I'll 
enable desktop effects (with no other 3D apps currently running)? Which KWin 
mode is better - XRender or OpenGL?
2) Which output is better for MPlayer - xv or something else?

some questions

[Zoltan Herczeg]

Hi,

I have finished my work on the diver for the simulator, and it works fine.
I am still wondering about some questions, though:

1) can I set the bssid of an ad-hoc network (using ioctl or netlink)? The
bssid is generated by get_random_bytes in mac80211/ibss.c, and if two
devices start the join in the same time (in ms), they will create
different bssids, even if their ssid are the same (another solution: the
bssid could be generated by a hash function from the ssid).

2) if we have two networks, with the same ibss ssid but different bssid,
and all nodes are brought to the same place (they can communicate with
each other now, which was not possible before), how would be the two
networks merge into one, which use the same bssid? How much time does it
need?

Regards,
Zoltan

Some questions

[Tiago Maluta]

Hi,

One of topic of my final course work that I thought is create a simple way to
demonstrate the DVB in Linux (software-only approach). Something like:

FRONTEND -> DEMUX -> AUDIO/VIDEO -> PLAYER

Notes:
- I'm omitting the block referring to SEC and CA.
- As I'm in Brazil I'm focusing in ISDB-T standard

My first step is create a code based in dvb_dummy_fe.c to take a place of a
'dummy' ISDB-T frontend. After that created a userspace program to 'inject' a
TS into the frontend. I know that is useless if I already have the Transport
Stream but I like to at least pass trough 'frontendX' device.

1) Where is /dev/dvb/adapter/frontendX created? I saw that in dvbdev.c,
but when I load dvb_dummy_fe.ko frontendX would not have to appear?

2) As dvb_dummy_fe.c doesn't have module_init() and module_exit() definition.
(and noted that this happens in other files in frontend/ too) is API
(Frontend Function Calls) used to access,
i.e: ioctl(fd, FE_GET_FRONTEND, struct ....)

Other information:

- I'm using 2.6.33-git
- $ grep ^CONFIG_DVB .config

    CONFIG_DVB_CORE=y
    CONFIG_DVB_MAX_ADAPTERS=8
    CONFIG_DVB_CAPTURE_DRIVERS=y
    CONFIG_DVB_FE_CUSTOMISE=y
    CONFIG_DVB_DUMMY_FE=m


Another topic that I would add is my work is regarded to userspace tools [1]
to processing the sections related do ISDB-T.

[1] http://linuxtv.org/hg/~pb/dvb-apps-isdbt

I would appreciate if developers in this maillist point some directions. Mauro
and Patrick answered some private emails with questions, but I like to exchange
discussion.

Maybe what I said it thoroughly out of context and I'm thinking on the
wrong way,
but except linuxtv.org and kernel Documentation/ it's difficult to get
 expertise
in topics regarded what could be a cool way to do a good final
course work.

Kind regards,

--tm

Re: some questions

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> Thomas Pasch <thomas.pasch@jentro.com> writes:
> 
> > I try to migrate our old cvs repo to git.
> > However, I still have to following questions
> > that I found difficult to answer with
> > the documentation.
> > 
> > - Is there a way to convert a indexVersion 1
> >   repo to indexVersion 2? (And vice versa?)
> 
> I think the only solution is to simply remove index,
> ensure configuration (pack.indexVersion), and recreate
> it using git-index-pack(1).

Just change pack.indexVersion in .git/config to have the version
you want and run `git gc` to repack the repository.  If you created
this repository by cloning another you may need to first delete
any .keep files:

	rm -f .git/objects/pack/*.keep
  
> > - Is there a way to find out if a repository
> >   is indexVersion 1 or indexVersion 2 (from
> >   the pack/index files)?
> 
> There is some magic number used to distinguish between
> pack index version 1 and version 2.
> 
> See Documentation/technical/pack-format.txt for details.

  for i in .git/objects/pack/pack-*.idx; do
  dd if=$i bs=12 count=1 | od -c
  done

A line like:

0000000   �   t   O   c  \0  \0  \0 002  \0  \0  \0 002

indicates index version 2, as it has the magic byte sequence in
front of '\xFFt0c'.  Most version 1 indexes will have 2 zeros
in the first two bytes:

0000000  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0 003

> > - http for git seems to be read-only/fetch.
> >   Would it be (theoretically) possible to
> >   support write/push (with WebDAV or so)?
> 
> It *is* supported (via https).
> 
> There was even attempt to create 'smart' http
> push via web server module or CGI script, but
> IIRC it hit feature freeze and discussion petered
> out, so only parts of it are in 'pu'.
> 
> Search for "Add Git-aware CGI for Git-aware smart
> HTTP transport", "More on git over HTTP POST"
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/91104

I'm picking this up again and working on it more.  Its not dead.
  
> > - What would be the implication to mount the
> >   git repo with nts (or another remote fs).
> >   Is it save to use such a mounted repo from
> >   more than one computer?

I've found that accessing a Git pack file over a network file
system like NFS or SMB is kinda slow.  The issue is we do many
reads scattered throughout the file.  Its hard for the client
to batch up reads and hide the network latency.

You may get better performance by building Git without mmap
support:

	make NO_MMAP=1

but that is going to hurt access to local files.

-- 
Shawn.

Re: some questions

[Shawn O. Pearce]

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Thomas Pasch <thomas.pasch@jentro.com> writes:
> >
> > I try to migrate our old cvs repo to git.
> > However, I still have to following questions
> > that I found difficult to answer with
> > the documentation.
> >
> > - Is there a way to convert a indexVersion 1
> >   repo to indexVersion 2? (And vice versa?)
> 
> The index itself is just a little file in .git/index. There might be a
> better solution, but just
> 
>   rm .git/index
>   git reset
> 
> seems to do it (of course, don't do while you have staged changes in
> the index !).

True, that would reset the dircache (aka .git/index).  But we only
have effectively 1 version of the dircache.  Sure there was an older
version, way back before it got a version header and the ability to
get extension sections added.  I don't think there are many clients
using that format anymore.  That format predates the 1.4 series,
and we really encourage people to be on 1.5 or later.

The original poster asked about indexVersion 1 and indexVersion 2,
which means he is probably talking about pack.indexVersion and thus
a .idx file alongside a pack, not the dircache file that tracks
the working tree state.
 
-- 
Shawn.

Re: some questions

[Jakub Narebski]

Thomas Pasch <thomas.pasch@jentro.com> writes:

> I try to migrate our old cvs repo to git.
> However, I still have to following questions
> that I found difficult to answer with
> the documentation.
> 
> - Is there a way to convert a indexVersion 1
>   repo to indexVersion 2? (And vice versa?)

I think the only solution is to simply remove index,
ensure configuration (pack.indexVersion), and recreate
it using git-index-pack(1).
 
> - Is there a way to find out if a repository
>   is indexVersion 1 or indexVersion 2 (from
>   the pack/index files)?

There is some magic number used to distinguish between
pack index version 1 and version 2.

See Documentation/technical/pack-format.txt for details.

> - http for git seems to be read-only/fetch.
>   Would it be (theoretically) possible to
>   support write/push (with WebDAV or so)?

It *is* supported (via https).

There was even attempt to create 'smart' http
push via web server module or CGI script, but
IIRC it hit feature freeze and discussion petered
out, so only parts of it are in 'pu'.

Search for "Add Git-aware CGI for Git-aware smart
HTTP transport", "More on git over HTTP POST"

  http://thread.gmane.org/gmane.comp.version-control.git/91104
 
> - I do not fully understand the implication
>   of 'git repack -a' (or 'git repack -A -d').
>   Is this bad for remote repos that are used
>   with http? (as '-a' is 'Especially useful when
>   packing a repository that is used for private
>   development and there is no need to worry about
>   people fetching via dumb protocols from it').

Dumb protocols currently _always_ download whole packfiles,
so if you want to serve dumb protocols you might want to
offer (also?) smaller packfiles.  You can, for example,
use .keep files and 'git repack -a' wouldn't matter.

You can try to search archives for "generational packing"
or something like that...

> - What would be the implication to mount the
>   git repo with nts (or another remote fs).
>   Is it save to use such a mounted repo from
>   more than one computer?

Should work without problems, _unless_ you mean that
you want to use multiple working directories with single
repository.  Then there are a couple of thing that you
have to be beware of (but you can instead use alternates
mechanism).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: some questions

[Matthieu Moy]

Thomas Pasch <thomas.pasch@jentro.com> writes:

> Hello,
>
> I try to migrate our old cvs repo to git.
> However, I still have to following questions
> that I found difficult to answer with
> the documentation.
>
> - Is there a way to convert a indexVersion 1
>   repo to indexVersion 2? (And vice versa?)

The index itself is just a little file in .git/index. There might be a
better solution, but just

  rm .git/index
  git reset

seems to do it (of course, don't do while you have staged changes in
the index !).

> - http for git seems to be read-only/fetch.
>   Would it be (theoretically) possible to
>   support write/push (with WebDAV or so)?

http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt

(BTW, that's the first result in
http://www.google.com/search?q=git+webdav ;-) )

-- 
Matthieu

some questions

[Thomas Pasch]

Hello,

I try to migrate our old cvs repo to git.
However, I still have to following questions
that I found difficult to answer with
the documentation.

- Is there a way to convert a indexVersion 1
  repo to indexVersion 2? (And vice versa?)

- Is there a way to find out if a repository
  is indexVersion 1 or indexVersion 2 (from
  the pack/index files)?

- http for git seems to be read-only/fetch.
  Would it be (theoretically) possible to
  support write/push (with WebDAV or so)?

- I do not fully understand the implication
  of 'git repack -a' (or 'git repack -A -d').
  Is this bad for remote repos that are used
  with http? (as '-a' is 'Especially useful when
  packing a repository that is used for private
  development and there is no need to worry about
  people fetching via dumb protocols from it').

- What would be the implication to mount the
  git repo with nts (or another remote fs).
  Is it save to use such a mounted repo from
  more than one computer?

Kind regards,

Thomas

-- 

Re: some questions

[Ryusuke Konishi]

> > 3. How robust is nilfs to device errors like bad sectors ? For example 
> > if you have a disk image where bad sectors are replaced by zeros, will 
> > you still be able to recover data from other sectors ?
> 
> When NILFS detects an I/O error, it tries to mark the segment including
> the bad block erroneous. The errorneous segment will never be reused.

For the latter question, the current NILFS does not have this kind of data
integrity.

Of course there are various opinions or ideas in the team.
I think, I'd like to make use of HW support such as SCSI DIF if Linux bio
will support it.

Regards,
Ryusuke Konishi

Re: some questions

[Ryusuke Konishi]

Hi,

From: David Arendt <admin-/LHdS3kC8BfYtjvyW6yDsg@public.gmane.org>
Subject: [NILFS users] some questions
Date: Sun, 04 May 2008 18:16:59 +0200
> I am very interested in nilfs2 so I have some questions ?

Sure.

> 1. If I understood well, nilfs is always appending to the end (is this 
> true or is also other data modified, for example to update pointers ?). 
> What is happening if I have deleted files and cleanerd deletes the 
> snapshots ?

If you deletes files, new directory blocks that doesn't have their
entries, are just written out.
When the cleanerd finds a block that is not referred to from any
snapshots, it is identified as removable and will not be copied
during reclamation.

> Will this space be written by further write operations or 
> will it be lost ?

Eventually the abandoned block will be overrode with a new block.

(To be more exact, NILFS manages disk space with units of segments;
 the cleanerd reclaims segments instead of disk blocks. )

> 2. I suppose that some fragmentation will build up, is there any 
> defragmentation tool planned ?

The former is yes.  Unfortunetely, the latter, no.
Though some LFSes defrags during GC, our LFS not.

> 3. How robust is nilfs to device errors like bad sectors ? For example 
> if you have a disk image where bad sectors are replaced by zeros, will 
> you still be able to recover data from other sectors ?

When NILFS detects an I/O error, it tries to mark the segment including
the bad block erroneous. The errorneous segment will never be reused.

Cheers,
Ryusuke Konishi

some questions

[David Arendt]

I am very interested in nilfs2 so I have some questions ?

1. If I understood well, nilfs is always appending to the end (is this 
true or is also other data modified, for example to update pointers ?). 
What is happening if I have deleted files and cleanerd deletes the 
snapshots ? Will this space be written by further write operations or 
will it be lost ?
2. I suppose that some fragmentation will build up, is there any 
defragmentation tool planned ?
3. How robust is nilfs to device errors like bad sectors ? For example 
if you have a disk image where bad sectors are replaced by zeros, will 
you still be able to recover data from other sectors ?

RE: Some Questions

[James Scott]

Thanks Morten.

Your answer has pointed me in the right direction :)

Regards,

James
 

> -----Original Message-----
> From: Morten K. Poulsen [mailto:morten@afdelingp.dk] 
> Sent: Saturday, 26 April 2008 7:49 p.m.
> To: James Scott
> Cc: mlmmj@mmj.dk
> Subject: Re: Some Questions
> 
> Hi James,
> 
> On Fri, 2008-04-25 at 21:06 +1200, James Scott wrote:
> > 1.  Configuring a mail list to allow subscribers only to post
> 
> >From the TUNABLES documentation:
> 
> . subonlypost          (boolean)
> 
> When this file is present, only people who are subscribed to the list,
> are allowed to post to it. The check is made against the 
> "From:" header.
>  
> > 2.  Auxiliary address that may post but not receive 
> messages (just put
> > addresses in "nomailsubs.d"?)
> 
> Yes.
>  
> > 3. Procedure for moderators to approve messages posted by
> > non-subscribers
> 
> >From the TUNABLES documentation:
> 
> . modnonsubposts       (boolean)
> 
> When this file is present and subonlypost is enabled, all 
> postings from
> people who are not subscribed to the list will be moderated.
>  
> > 4 Web interfaces for: admin, archives, user subscription management.
> 
> See the contrib/web/ directory.
> 
> > 5. Custom footers (the file 'control/footers" seems to be ignored).
> 
> >From the README documentation:
> 
> 7) If you want every mail to have something like:
>    --
>    To unsubscribe send a mail to coollist+unsubscribe@lists.domain.net
> 
>    Just add what you want to a file named "footer" in the same dir as
>    "customheader" (listdir/control/).
> 
> Hint: "footer" not "footers"
> 
> 
> I hope this answered your questions.
> 
> 
> Morten

Re: Some Questions

[Morten K. Poulsen]

Hi James,

On Fri, 2008-04-25 at 21:06 +1200, James Scott wrote:
> 1.  Configuring a mail list to allow subscribers only to post

From the TUNABLES documentation:

· subonlypost          (boolean)

When this file is present, only people who are subscribed to the list,
are allowed to post to it. The check is made against the "From:" header.
 
> 2.  Auxiliary address that may post but not receive messages (just put
> addresses in "nomailsubs.d"?)

Yes.
 
> 3. Procedure for moderators to approve messages posted by
> non-subscribers

From the TUNABLES documentation:

· modnonsubposts       (boolean)

When this file is present and subonlypost is enabled, all postings from
people who are not subscribed to the list will be moderated.
 
> 4 Web interfaces for: admin, archives, user subscription management.

See the contrib/web/ directory.

> 5. Custom footers (the file 'control/footers" seems to be ignored).

From the README documentation:

7) If you want every mail to have something like:
   --
   To unsubscribe send a mail to coollist+unsubscribe@lists.domain.net

   Just add what you want to a file named "footer" in the same dir as
   "customheader" (listdir/control/).

Hint: "footer" not "footers"


I hope this answered your questions.


Morten

Some Questions

[James Scott]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Hi,
 
I have mlmmj v1.2.15 installed on Fedora 7 (using the fedora RPM package).
 
I would appreciate any advice on the following:
 
1.  Configuring a mail list to allow subscribers only to post
 
2.  Auxiliary address that may post but not receive messages (just put
addresses in "nomailsubs.d"?)
 
3. Procedure for moderators to approve messages posted by non-subscribers
 
4 Web interfaces for: admin, archives, user subscription management.
 
5. Custom footers (the file 'control/footers" seems to be ignored).
 
Regards,
 
James Scott
 

[-- Attachment #2: Type: text/html, Size: 2501 bytes --]

Some questions

[Joerg Sommer]

Hi,

I've downloaded hotplug-2003_08_05 and have some questions about the code:

* Why not remove the bashism?

sbin/hotplug:
* Why not include the test for -x in the if expression?
  	if [ -f $I -a -x $I ]; then
		$I $1 ;
	fi
* Why returns this script with exit code 1? Doesn't this stand for an
  error?

#v+
diff -ur hotplug-2003_08_05.orig/sbin/hotplug hotplug-2003_08_05/sbin/hotplug
--- hotplug-2003_08_05.orig/sbin/hotplug        2003-06-28 02:13:10.000000000 +0
+++ hotplug-2003_08_05/sbin/hotplug     2003-08-19 16:21:38.000000000 +0200
@@ -28,8 +28,8 @@
 DIR="/etc/hotplug.d"
 
 for I in "${DIR}/$1/"*.hotplug "${DIR}/"default/*.hotplug ; do
-       if [ -f $I ]; then
-               test -x $I && $I $1 ;
+       if [ -f $I -a -x $I ]; then
+               $I $1
        fi
 done
 
#v-

etc/hotplug.d/default/default.hotplug:
* l.46: Why use sed to strip the tailing .agent? This causes a pipe
  and another command, even though, this could be done by basename.
* l.67: Why do you debug handling by hand? There is a function
  debug_mesg, so this shouldn't be necessary.
* If default.hotplug is called in the right way, you check, if the agent
  is executable. If not, it fails. So you can't name nonexecutable agents
  in l.53.
* I think a $(set -e) is essential, because a cd to /etc/hotplug could
  fail.
* To source hotplug.functions a path must be named, otherwise
  hotplug.functions is searched in the directories of $PATH, which should
  fail. See Posix 1003.2 3.14.4.

#v+
diff -ur hotplug-2003_08_05.orig/etc/hotplug.d/default/default.hotplug hotplug-2003_08_05/etc/hotplug.d/default/default.hotplug
--- hotplug-2003_08_05.orig/etc/hotplug.d/default/default.hotplug	2003-05-02 07:01:45.000000000 +0200
+++ hotplug-2003_08_05/etc/hotplug.d/default/default.hotplug	2003-08-19 16:26:07.000000000 +0200
@@ -23,10 +23,12 @@
 # $Id: default.hotplug,v 1.1 2003/05/02 05:01:45 kroah Exp $
 #
 
-cd /etc/hotplug
-. hotplug.functions
+set -e
+
+# export DEBUG=yes
 
-# DEBUG=yes export DEBUG
+cd /etc/hotplug
+. ./hotplug.functions
 
 debug_mesg "arguments ($*) env (`env`)"
 
@@ -38,19 +40,16 @@
 # through argv.
 # 
 if [ $# -lt 1 -o "$1" = "help" -o "$1" = "--help" ]; then
-    if [ -t ]; then
+    if [ -t 1 ]; then
 	echo "Usage: $0 AgentName [AgentArguments]"
 
-	AGENTS=""
-	for AGENT in /etc/hotplug/*.agent ; do
-	    TYPE=`basename $AGENT | sed s/.agent//`
+	printf "AgentName values on this system:"
+	for AGENT in $HOTPLUG_DIR/*.agent ; do
 	    if [ -x $AGENT ]; then
-		AGENTS="$AGENTS $TYPE"
-	    else
-		AGENTS="$AGENTS ($TYPE)"
+		printf " `basename $AGENT .agent`"
 	    fi
 	done
-	echo "AgentName values on this system: $AGENTS" 
+	echo
     else
 	mesg "illegal usage $*"
     fi
@@ -61,12 +60,10 @@
 # Delegate event handling:
 #   /sbin/hotplug FOO ..args.. ==> /etc/hotplug/FOO.agent ..args..
 #
-AGENT=/etc/hotplug/$1.agent
+AGENT=$HOTPLUG_DIR/$1.agent
 if [ -x $AGENT ]; then
     shift
-    if [ "$DEBUG" != "" ]; then
-	mesg "invoke $AGENT ($@)"
-    fi
+    debug_mesg "invoke $AGENT ($@)"
     exec $AGENT "$@"
     mesg "couldn't exec $AGENT"
     exit 1
#v-

etc/hotplug/hotplug.functions:
* Posix logger doesn't know the option -t. If you depend on BSD logger,
  it may be possible to specify the priority of the messages. In this
  case, I would propose to add a function error_mesg(), hat logs on
  stderr or use level debug for logger. As a whole, I would propose in
  this case, to log to facility daemon.

#v+
diff -ur hotplug-2003_08_05.orig/etc/hotplug/hotplug.functions hotplug-2003_08_05/etc/hotplug/hotplug.functions
--- hotplug-2003_08_05.orig/etc/hotplug/hotplug.functions	2003-06-28 02:13:10.000000000 +0200
+++ hotplug-2003_08_05/etc/hotplug/hotplug.functions	2003-08-19 17:36:55.000000000 +0200
@@ -10,7 +10,7 @@
 #
 #
 
-# DEBUG=yes; export DEBUG
+# export DEBUG=yes
 PATH=/bin:/sbin:/usr/sbin:/usr/bin
 
 KERNEL=`uname -r`
@@ -22,31 +22,31 @@
     . /etc/sysconfig/hotplug
 fi
 
-if [ -x /usr/bin/logger ]; then
-    LOGGER=/usr/bin/logger
-elif [ -x /bin/logger ]; then
-    LOGGER=/bin/logger
-else
-    unset LOGGER
-fi
 #
 # for diagnostics
 #
-if [ -t -o -z "$LOGGER" ]; then
+if [ -t 1 -o ! \( -x /usr/bin/logger -o -x /bin/logger \) ]; then
     mesg () {
 	echo "$@"
     }
+    if [ "$DEBUG" = yes ]; then
+	debug_mesg () {
+	    echo "$@"
+	}
+    else
+	debug_mesg () {
+	    :
+	}
+    fi
 else
     mesg () {
-	$LOGGER -t $(basename $0)"[$$]" "$@"
+	logger $(basename $0)"[$$] $@"
+    }
+    debug_mesg () {
+	logger $(basename $0)"[$$] $@"
     }
 fi
 
-debug_mesg () {
-    test "$DEBUG" = "" -o "$DEBUG" = no && return
-    mesg "$@"
-}
-
 #
 # The modules.*map parsing uses BASH ("declare -i") and some version
 # of AWK, typically /bin/gawk.  Most GNU/Linux distros have these,
@@ -80,23 +80,18 @@
 #
 load_drivers ()
 {
-    local LOADED TYPE FILENAME DESCRIPTION LISTER
-    DRIVERS=""
-
     # make this routine more readable
     TYPE=$1
     FILENAME=$2
     DESCRIPTION=$3
 
+    DRIVERS=""
     # should we use usbmodules, pcimodules?  not on 2.5+, because sysfs
     # ought to expose the data we need to find all candidate drivers.
     # (on 2.5.48 it does for usb; but maybe not yet for pci.)
     case "$KERNEL" in
-    2.2*|2.3*|2.4*)	LISTER=`type -p ${TYPE}modules` ;;
-    *)			LISTER="" ;;
-    esac
-
-    if [ "$LISTER" != "" ]; then
+    2.2*|2.3*|2.4*)
+        LISTER=`type -p ${TYPE}modules`
 	# lister programs MIGHT be preferable to parsing from shell scripts:
 	# - usbmodules used for (a) multi-interface devices, (b) coldplug
 	# - pcimodules used only for coldplug
@@ -106,27 +101,26 @@
 	    # only works if we have usbfs
 	    # ... reads more descriptors than are passed in env
 	    # ... doesn't handle comment syntax either
-	    if [ "$DEVICE" = "" -o ! -f "$DEVICE" ]; then
-		LISTER=
-	    else
+	    if [ -f "$DEVICE" ]; then
 		DRIVERS=`$LISTER --mapfile $FILENAME --device $DEVICE`
-	    fi ;;
-
+	    fi
+	    ;;
 	pci)
 	    debug_mesg "pcimodules is scanning more than $PCI_SLOT ..."
 	    DRIVERS=`$LISTER`
 	    ;;
 	esac
-    fi
+	;;
+    esac
 
     # try parsing by shell scripts if no luck yet
-    if [ "$DRIVERS" = "" ]; then
+    if [ -z "$DRIVERS" ]; then
 	${TYPE}_map_modules < $FILENAME
     fi
 
     # FIXME remove dups and blacklisted modules from $DRIVERS here
 
-    if [ "$DRIVERS" = "" ]; then
+    if [ -z "$DRIVERS" ]; then
 	return
     fi
 
@@ -139,9 +133,8 @@
     do
 	# maybe driver modules need loading
         LOADED=false
-	if ! lsmod | grep -q "^$MODULE " > /dev/null 2>&1; then
-	    if grep -q "^$MODULE\$" $HOTPLUG_DIR/blacklist \
-		    >/dev/null 2>&1; then
+	if ! lsmod | grep -q "^$MODULE "; then
+	    if grep -q "^$MODULE\$" $HOTPLUG_DIR/blacklist; then
 		debug_mesg "... blacklisted module:  $MODULE"
 		continue
 	    fi
@@ -167,8 +160,7 @@
 	# giving kernel code another chance.
 	if [ -x $HOTPLUG_DIR/$TYPE/$MODULE ]; then
 	    debug_mesg Module setup $MODULE for $DESCRIPTION
-	    $HOTPLUG_DIR/$TYPE/$MODULE
-	    LOADED=true
+	    $HOTPLUG_DIR/$TYPE/$MODULE && LOADED=true
 	fi
 
 	if [ $LOADED = false ]; then
#v-

Bye, Joerg.

-- 
»Perl - the only language that looks the same
 before and after RSA encryption.«           -- Keith Bostic


-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code\x104
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some questions

[Michel Dänzer]

On Mit, 2003-03-12 at 09:24, Geert Uytterhoeven wrote:
> On 12 Mar 2003, Michel [ISO-8859-1] Dänzer wrote:
> > On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > > > 
> > > > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > > > aty, radeon, etc can turn this on).
> > > > > > 
> > > > > > What exactly is a "trusted" console?
> > > > > 
> > > > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > > > we can safely assume that the hardware state is still sane, and if not,
> > > > > assume the hardware state is undefined.
> > > > 
> > > > Can you also detect when the app has opened the framebuffer device, and
> > > > assume it's playing nice when it has? (for Option "UseFBDev")
> > > 
> > > X using fbdev will also have the same limitation. I have implemented
> > > something like this before.  For each fb_open, the current->pid can be
> > > saved into a "white list" and removed for each fb_close.  fbcon can then
> > > compare this to the pid of the vt it's switching from.
> 
> The application cannot play not nice unless it mmap()s the MMIO registers. To
> be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_flags.

X will map the MMIO registers with Option "UseFBDev" and still play nice
(hopefully :).

> > > This is becoming to sound very ugly though.  I guess, the best way is to
> > > really support Option "UseFBDev", or at least have the user decide if
> > > he/she wants to have the hardware refreshed.  
> > 
> > I'm afraid I don't understand what you're saying here.
> 
> But I think you do agree :-) He says that if fbdev is active, the X server has
> to be fbdev compliant and thus not mess with the hardware where it's not
> allowed to.

I agree that's how it should be.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Geert Uytterhoeven]

On 12 Mar 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > > 
> > > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > > aty, radeon, etc can turn this on).
> > > > > 
> > > > > What exactly is a "trusted" console?
> > > > 
> > > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > > we can safely assume that the hardware state is still sane, and if not,
> > > > assume the hardware state is undefined.
> > > 
> > > Can you also detect when the app has opened the framebuffer device, and
> > > assume it's playing nice when it has? (for Option "UseFBDev")
> > 
> > X using fbdev will also have the same limitation. I have implemented
> > something like this before.  For each fb_open, the current->pid can be
> > saved into a "white list" and removed for each fb_close.  fbcon can then
> > compare this to the pid of the vt it's switching from.

The application cannot play not nice unless it mmap()s the MMIO registers. To
be able to do that, it first has to clear FB_ACCELF_TEXT in var.accel_flags.

> > This is becoming to sound very ugly though.  I guess, the best way is to
> > really support Option "UseFBDev", or at least have the user decide if
> > he/she wants to have the hardware refreshed.  
> 
> I'm afraid I don't understand what you're saying here.

But I think you do agree :-) He says that if fbdev is active, the X server has
to be fbdev compliant and thus not mess with the hardware where it's not
allowed to.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Michel Dänzer]

On Mit, 2003-03-12 at 02:02, Antonino Daplas wrote:
> On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> > On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > > 
> > > > > I actually prefer #3, and I already have working code for this.  We can
> > > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > > can disable this, and only drivers that are affected such as the riva,
> > > > > aty, radeon, etc can turn this on).
> > > > 
> > > > What exactly is a "trusted" console?
> > > 
> > > By default, the pid of each vt is -1.  When X loads, it installs its own
> > > VT (ie vt7), which in that case the pid of that particular vt == X's
> > > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > > we can safely assume that the hardware state is still sane, and if not,
> > > assume the hardware state is undefined.
> > 
> > Can you also detect when the app has opened the framebuffer device, and
> > assume it's playing nice when it has? (for Option "UseFBDev")
> > 
> 
> X using fbdev will also have the same limitation. I have implemented
> something like this before.  For each fb_open, the current->pid can be
> saved into a "white list" and removed for each fb_close.  fbcon can then
> compare this to the pid of the vt it's switching from.

I see, makes sense.

> This is becoming to sound very ugly though.  I guess, the best way is to
> really support Option "UseFBDev", or at least have the user decide if
> he/she wants to have the hardware refreshed.  

I'm afraid I don't understand what you're saying here.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 08:07, Michel Dänzer wrote:
> On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> > On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > > 
> > > > I actually prefer #3, and I already have working code for this.  We can
> > > > also make this driver switchable (ie, drivers that are not affected by X
> > > > can disable this, and only drivers that are affected such as the riva,
> > > > aty, radeon, etc can turn this on).
> > > 
> > > What exactly is a "trusted" console?
> > 
> > By default, the pid of each vt is -1.  When X loads, it installs its own
> > VT (ie vt7), which in that case the pid of that particular vt == X's
> > pid.  We can check this pid, and if switching from a vt with pid == -1,
> > we can safely assume that the hardware state is still sane, and if not,
> > assume the hardware state is undefined.
> 
> Can you also detect when the app has opened the framebuffer device, and
> assume it's playing nice when it has? (for Option "UseFBDev")
> 

X using fbdev will also have the same limitation. I have implemented
something like this before.  For each fb_open, the current->pid can be
saved into a "white list" and removed for each fb_close.  fbcon can then
compare this to the pid of the vt it's switching from.

This is becoming to sound very ugly though.  I guess, the best way is to
really support Option "UseFBDev", or at least have the user decide if
he/she wants to have the hardware refreshed.  

Tony   





-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Michel Dänzer]

On Die, 2003-03-11 at 23:51, Antonino Daplas wrote:
> On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > > 
> > > I actually prefer #3, and I already have working code for this.  We can
> > > also make this driver switchable (ie, drivers that are not affected by X
> > > can disable this, and only drivers that are affected such as the riva,
> > > aty, radeon, etc can turn this on).
> > 
> > What exactly is a "trusted" console?
> 
> By default, the pid of each vt is -1.  When X loads, it installs its own
> VT (ie vt7), which in that case the pid of that particular vt == X's
> pid.  We can check this pid, and if switching from a vt with pid == -1,
> we can safely assume that the hardware state is still sane, and if not,
> assume the hardware state is undefined.

Can you also detect when the app has opened the framebuffer device, and
assume it's playing nice when it has? (for Option "UseFBDev")


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> The accel engine is probably not a problem if it uses mmio.  However,
> engines that use command buffers are more susceptible to this if the
> buffers can be dynamically allocated by the process.

OK, ack.

> 
> The i810 for instance uses ringbuffers.  It has to be dynamically
> allocated via agpgart.  Fortunately, the i810 can support 2 ringbuffers,
> so X can use one and fb the other, so there's no conflict. 
> 
> Then you also have DRI joining in the confusion :-)

Not in my case :) The SiS DRI stuff is made in a way to prevent problems 
of this kind. But I ack that it might be on others.

> The best solution, personally, is to have one module controlling chipset
> access -- DRM for 2D and 3D, and fb for video mode switching.

Well. I personally don't want every graphics application to depend on 
kernel modules.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 06:27, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > Unfortunately, this is what we are trying to prevent.  X assumes that
> > the console is in text mode, so only registers that affect text mode are
> > restored.  Frequently, cursor registers and bitmaps, as an example, are
> > not refreshed.  There's probably more, ie accel engine, etc.
> 
> Argh.. of course, cursor and accelerator registers are usually not 
> restored, you're right at this. But the drivers usually leave the engine 
> in the same state as when started. (A "restore" of accelerator engine 
> registers is mostly impossible, because a complete restore would cause 
> the last command to be executed again)
> 

The accel engine is probably not a problem if it uses mmio.  However,
engines that use command buffers are more susceptible to this if the
buffers can be dynamically allocated by the process.

The i810 for instance uses ringbuffers.  It has to be dynamically
allocated via agpgart.  Fortunately, the i810 can support 2 ringbuffers,
so X can use one and fb the other, so there's no conflict. 

Then you also have DRI joining in the confusion :-)

The best solution, personally, is to have one module controlling chipset
access -- DRM for 2D and 3D, and fb for video mode switching.

Tony



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 06:23, Thomas Winischhofer wrote:
> > 
> > I actually prefer #3, and I already have working code for this.  We can
> > also make this driver switchable (ie, drivers that are not affected by X
> > can disable this, and only drivers that are affected such as the riva,
> > aty, radeon, etc can turn this on).
> 
> What exactly is a "trusted" console?
> 

By default, the pid of each vt is -1.  When X loads, it installs its own
VT (ie vt7), which in that case the pid of that particular vt == X's
pid.  We can check this pid, and if switching from a vt with pid == -1,
we can safely assume that the hardware state is still sane, and if not,
assume the hardware state is undefined.

Tony




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> Unfortunately, this is what we are trying to prevent.  X assumes that
> the console is in text mode, so only registers that affect text mode are
> restored.  Frequently, cursor registers and bitmaps, as an example, are
> not refreshed.  There's probably more, ie accel engine, etc.

Argh.. of course, cursor and accelerator registers are usually not 
restored, you're right at this. But the drivers usually leave the engine 
in the same state as when started. (A "restore" of accelerator engine 
registers is mostly impossible, because a complete restore would cause 
the last command to be executed again)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>>>2. do not refresh unless var changed - fasted but can result in
>>>corruption/crash if registers were changed behind the back of fbdev
>>
>>I think one can rely on tidyness of applications changing the registers. 
>>Like X does.
> 
>  
> Unfortunately, this is what we are trying to prevent.  X assumes that
> the console is in text mode, so only registers that affect text mode are
> restored.  Frequently, cursor registers and bitmaps, as an example, are
> not refreshed.  There's probably more, ie accel engine, etc.

That surprises me. The X drivers I looked at (quite a bunch) restore all 
registers (that need to be restored, that is)

>>>3. selective refresh - do not refresh if switching between "trusted"
>>>consoles, refresh if switching from "untrusted" consoles.
>>
> 
> I actually prefer #3, and I already have working code for this.  We can
> also make this driver switchable (ie, drivers that are not affected by X
> can disable this, and only drivers that are affected such as the riva,
> aty, radeon, etc can turn this on).

What exactly is a "trusted" console?

Thomas


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 04:56, Thomas Winischhofer wrote:
> > 
> > The choices are:
> > 
> > 1. refresh the registers at every switch - slowest but guarantees
> > hardware state is always preserved 
> 
> Bad. Takes long time, especially on LCD displays which always need a 
> little delay for backlight and sync stability reasons.
> 
> > 2. do not refresh unless var changed - fasted but can result in
> > corruption/crash if registers were changed behind the back of fbdev
> 
> I think one can rely on tidyness of applications changing the registers. 
> Like X does.
 
Unfortunately, this is what we are trying to prevent.  X assumes that
the console is in text mode, so only registers that affect text mode are
restored.  Frequently, cursor registers and bitmaps, as an example, are
not refreshed.  There's probably more, ie accel engine, etc.

Of course, X is not totally to blame, it's doing its best to restore the
console back.  It really depends on the X drivers, how complicated they
are, how comprehensive are their restore routines, etc.  

> > 3. selective refresh - do not refresh if switching between "trusted"
> > consoles, refresh if switching from "untrusted" consoles.

I actually prefer #3, and I already have working code for this.  We can
also make this driver switchable (ie, drivers that are not affected by X
can disable this, and only drivers that are affected such as the riva,
aty, radeon, etc can turn this on).

Tony



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
>>However, the brokenness is really on the driver side.  They are unable
>>to change the video mode unless they are supplied with the correct
>>timing parameters where in fact they actually have the best knowledge on
>>how to calculate them.  
>>
>>So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
>>we let the drivers calculate it for themselves?  I go for the latter, as
>>fbcon really should not have any business with hardware.
> 
> 
> I agree. 

Me Too(tm). SiSfb (sorry for mentioning this one over and over, but 
that's the only one I am working on) does that now, according to the 
following assumptions:

If old_x == new_x && old_y == new_y && old_clock == new_clock

	-> assume a change in depth, hence recalculate the clock
	based on the htotal and vtotal values (which are calculated
	using var's horizontal and vertical timing.

else if (old_x != new_x || old_y != new_y) && old_clock == new_clock

	-> assume a mode change originating from fbcon_resize (where
	only xres and yres are changed, everything else left unchanged; 	 
hence, use the default clock (user selectable) because clock is
	invalid.

else if(timings are valid)

	-> use these timings, they originate from an application
	using the framebuffer device properly (directFB, for instance)

else -> use default clock

Works perfectly. Tested all possible applications (mplayer, sdl stuff, 
etc), no problems.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> Well, you have info->currcon, fg_console etc...  No mapping is done,
> fbcon will just keep track of the tty's it's currently switched to (vt.c
> does it, and so does fbcon_switch), and fbcon will just look if the vc
> has a valid PID (which means a process installed its own vc) and
> therefore not trust it to completely preserve the graphics state.
> 
> Note that X does something like this to protect itself.  When switch
> from console to X, it refreshes its own registers.

Which does not neccessarily mean that the framebuffer driver must do the 
same, resulting in two mode switches. Not really healthy for LCD panels.

The current implementation (as with James' latest patch) does not show 
any problems with this, even when switching back to a console with a 
different resolution than the one X was started under. Then again, maybe 
that's just due to a all too well working sis driver combination :)

> I think you may need some support for this.  Several have already
> reported that switching from X to a console results in a corrupted
> display which can be cleared by doing an fbset. 
> 
> The choices are:
> 
> 1. refresh the registers at every switch - slowest but guarantees
> hardware state is always preserved 

Bad. Takes long time, especially on LCD displays which always need a 
little delay for backlight and sync stability reasons.

> 2. do not refresh unless var changed - fasted but can result in
> corruption/crash if registers were changed behind the back of fbdev

I think one can rely on tidyness of applications changing the registers. 
Like X does.

> 3. selective refresh - do not refresh if switching between "trusted"
> consoles, refresh if switching from "untrusted" consoles.
> 
> 4. Find a method to detect if the registers were changed behind the back
> of fbdev.

Very time taking on some hardware (such as ... erm... SiS) with more 
than 100 registers for graphic mode setup.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-12 at 00:29, James Simmons wrote:
> 
> > So, I think fbcon should also detect if the previous console is not
> > fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
> > it isn't, force an fb_set_par.
> 
> This whole idea of mapping a specific VC to a specific piece of hardware 
> is just plain dumb and overly complex. The new console system will 
> allocate a set of 16 console to each independent VT.
> 

Well, you have info->currcon, fg_console etc...  No mapping is done,
fbcon will just keep track of the tty's it's currently switched to (vt.c
does it, and so does fbcon_switch), and fbcon will just look if the vc
has a valid PID (which means a process installed its own vc) and
therefore not trust it to completely preserve the graphics state.

Note that X does something like this to protect itself.  When switch
from console to X, it refreshes its own registers.

I think you may need some support for this.  Several have already
reported that switching from X to a console results in a corrupted
display which can be cleared by doing an fbset. 

The choices are:

1. refresh the registers at every switch - slowest but guarantees
hardware state is always preserved 
 
2. do not refresh unless var changed - fasted but can result in
corruption/crash if registers were changed behind the back of fbdev

3. selective refresh - do not refresh if switching between "trusted"
consoles, refresh if switching from "untrusted" consoles.

4. Find a method to detect if the registers were changed behind the back
of fbdev.

Tony 



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[James Simmons]

> So, I think fbcon should also detect if the previous console is not
> fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
> it isn't, force an fb_set_par.

This whole idea of mapping a specific VC to a specific piece of hardware 
is just plain dumb and overly complex. The new console system will 
allocate a set of 16 console to each independent VT.




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[James Simmons]

> PS: James, are you "entitled" to add maintainers to the MAINTAINERS 
> file? I have actually been the maintainer of sisfb since a year back, so 
> I think this should perhaps be mentioned..?
> 
> SIS FRAMEBUFFER DRIVER
> P:	Thomas Winischhofer
> M:	thomas@winischhofer.net
> W:	http://www.winischhofer.net/linuxsisvga.shtml
> S:	Maintained

Added.




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[James Simmons]

> However, the brokenness is really on the driver side.  They are unable
> to change the video mode unless they are supplied with the correct
> timing parameters where in fact they actually have the best knowledge on
> how to calculate them.  
> 
> So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> we let the drivers calculate it for themselves?  I go for the latter, as
> fbcon really should not have any business with hardware.

I agree. 



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: Some questions

[Antonino Daplas]

On Sun, 2003-03-09 at 11:47, Thomas Winischhofer wrote:
> 
> > Granted, the patch I submitted was a quickwrite, never meant to be
> > applied but serves only to illustrate.  This is a more proper patch,
> > applied against James latest fbdev.diff.  It simplifies the equation,
> > remove the unnecessary 'if' conditional.  Apply it, don't apply it, I
> > don't care.
> 
> That's not up to me to decide. For me, the only thing that counts is 
> that the console can deal with text areas that are smaller than the 
> screen resolution. Besides, your last sentence was certainly not 
> neccessary. You among friends here.
> 

My apologies if I sounded too harsh, no offense was intended.  I just
meant that your code and mine achieves the same and (hopefully) correct
results  And because the code is in a non-performance critical section,
I don't care whichever is used (except for the var->yres and
info->var.yres issue).  

If the code affects a critical section (blitting, character painting,
etc), of course, that's another story.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino,
> Your example - 1024x768, yres_virtual = 1152, font = 8x16
> 
> 2 cases:  
> 
> 1. full screeen console
> vc->vc_rows = 48
> 
> p->vrows = 72 - (768/16 - 48)
> p->vrows = 72 - 0
> p->vrows = 72

You're right. I made a mistake in my calculation.

> Granted, the patch I submitted was a quickwrite, never meant to be
> applied but serves only to illustrate.  This is a more proper patch,
> applied against James latest fbdev.diff.  It simplifies the equation,
> remove the unnecessary 'if' conditional.  Apply it, don't apply it, I
> don't care.

That's not up to me to decide. For me, the only thing that counts is 
that the console can deal with text areas that are smaller than the 
screen resolution. Besides, your last sentence was certainly not 
neccessary. You among friends here.

Thomas


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 22:20, Thomas Winischhofer wrote:
> 
> 
> Continued:  What happens with your solution of the virtual area is only 
> 1.5 times the size of the visible area? Did your check this?
> 
>  >> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
>  >>+	p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
> 
> yres = 768
> yres_virtual = 1152
> fontheight= 16
> rows = 48
> 
> vrows = 1152 / 16 = 72
> 72 - (768 / 16) - 48 = -24
> 
> :) Any question?
> 
Why?

Your example - 1024x768, yres_virtual = 1152, font = 8x16

2 cases:  

1. full screeen console
vc->vc_rows = 48

p->vrows = 72 - (768/16 - 48)
p->vrows = 72 - 0
p->vrows = 72

2. half-height console:
vc->vc_rows = 24

p->vrows = 1152 - (768/16 - 24)
p->vrows = 72 - 24
p->vrows = 48

Second case, 24 rows are wasted, why? See accel_clear_margins:

ch = vc->vc_font_height
bh =  yres - (vc->vc_rows * ch)
bh = 768 - (24 * 16)
bh = 768 - 384
bh = 384

This means that a rectangle of height 384 scanlines (_always_) at the
bottom of the display will be cleared .  If you pan to the end of
graphics memory, attempting to clear from yres_virtual + 384 will cause
the chipset to crash.  But it won't because we reserved 24 rows (384
pixels) to accomodate this.

For the clincher, this is your code:

if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
	p->vrows -= (info->var.yres - (vc->vc_font.height * 		    
vc->vc_rows)) / vc->vc_font.height;
}

Simplifying the second line....

p->vrows -= (info->var.yres/vc->vc_font.height) - (vc->vc_font.height *
vc->vc_rows)/vc->vc_font.height;
p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;

Do you recognize the last line?  Yep, it's mine. It's also simpler (1
division and 1 subtraction vs 1 division, 1 multiplication and 1
subtraction). 

Code correctness was never the issue.  The only thing I'm questioning is
using info->var.yres instead of var.yres, and I have explained this
enough times already. 

Granted, the patch I submitted was a quickwrite, never meant to be
applied but serves only to illustrate.  This is a more proper patch,
applied against James latest fbdev.diff.  It simplifies the equation,
remove the unnecessary 'if' conditional.  Apply it, don't apply it, I
don't care.

Tony

diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-08 21:33:25.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 21:47:26.000000000 +0000
@@ -1044,9 +1044,7 @@
 		vc->vc_rows = nr_rows;
 	}
 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
-	if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
-		p->vrows -= (info->var.yres - (vc->vc_font.height * vc->vc_rows)) / vc->vc_font.height;
-	}
+	p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
 	if ((info->var.yres % vc->vc_font.height) &&
 	    (info->var.yres_virtual % vc->vc_font.height <
 	     info->var.yres % vc->vc_font.height))
@@ -1825,9 +1823,8 @@
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
 	}
-	p->vrows = var.yres_virtual/fh;
-	if(var.yres > (fh * (height + 1)))
-		p->vrows -= (var.yres - (fh * height)) / fh;
+	p->vrows = info->var.yres_virtual/fh;
+	p->vrows -= (info->var.yres + (fh - 1))/fh - height;
 	return 0;
 }
 
@@ -2099,11 +2096,7 @@
 		/* reset wrap/pan */
 		info->var.xoffset = info->var.yoffset = p->yscroll = 0;
 		p->vrows = info->var.yres_virtual / h;
-
-#if 0          /* INCOMPLETE - let the console gurus handle this */
-		if(info->var.yres > (h * (vc->vc_rows + 1))
-			p->vrows -= (info->var.yres - (h * vc->vc_rows)) / h;
-#endif
+		p->vrows -= info->var.yres/h  - vc->vc_rows;
 		if ((info->var.yres % h)
 		    && (info->var.yres_virtual % h < info->var.yres % h))
 			p->vrows--;



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Continued:  What happens with your solution of the virtual area is only 
1.5 times the size of the visible area? Did your check this?

 >> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
 >>+	p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;

yres = 768
yres_virtual = 1152
fontheight= 16
rows = 48

vrows = 1152 / 16 = 72
72 - (768 / 16) - 48 = -24

:) Any question?

Thomas


Antonino Daplas wrote:
> On Sat, 2003-03-08 at 08:58, Antonino Daplas wrote:
> 
>>On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
>>
>>>I don't see why this is simpler, but I do see it wastes a lot of screen 
>>>space :)
>>>
>>
>>yep, it'a a typo.
>>
>>Tony
>>
>>diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
>>--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
>>+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 00:49:09.000000000 +0000
>>@@ -1044,6 +1044,7 @@
>> 		vc->vc_rows = nr_rows;
>> 	}
>> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
>>+	p->vrows -= info->var.yres/h - vc->vc_rows;
> 
>                     ^^^^^^^^^^^^^^^^
> 
> I also meant info->var.yres/vc->vc_font.height :-)
> 
> Tony
> 
> 
> 


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>> 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
>>+	p->vrows -= info->var.yres/h - vc->vc_rows;
> 
>                     ^^^^^^^^^^^^^^^^
> 
> I also meant info->var.yres/vc->vc_font.height :-)

Tony,

Both ways it works, granted. But I still don't see the advantage of your 
solution over mine. Your's wastes an area of the size of a whole screen.

Certainly no offence, but can you explain why you think this is better?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 08:58, Antonino Daplas wrote:
> On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
> > I don't see why this is simpler, but I do see it wastes a lot of screen 
> > space :)
> > 
> 
> yep, it'a a typo.
> 
> Tony
> 
> diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
> --- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
> +++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 00:49:09.000000000 +0000
> @@ -1044,6 +1044,7 @@
>  		vc->vc_rows = nr_rows;
>  	}
>  	p->vrows = info->var.yres_virtual / vc->vc_font.height;
> +	p->vrows -= info->var.yres/h - vc->vc_rows;
                    ^^^^^^^^^^^^^^^^

I also meant info->var.yres/vc->vc_font.height :-)

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
> I don't see why this is simpler, but I do see it wastes a lot of screen 
> space :)
> 

yep, it'a a typo.

Tony

diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-08 00:49:09.000000000 +0000
@@ -1044,6 +1044,7 @@
 		vc->vc_rows = nr_rows;
 	}
 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
+	p->vrows -= info->var.yres/h - vc->vc_rows;
 	if ((info->var.yres % vc->vc_font.height) &&
 	    (info->var.yres_virtual % vc->vc_font.height <
 	     info->var.yres % vc->vc_font.height))
@@ -1821,8 +1822,9 @@
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
-		p->vrows = info->var.yres_virtual/fh;
 	}
+	p->vrows = info->var.yres_virtual/fh;
+	p->vrows -= (info->var.yres + (fh - 1))/fh - vc->vc_rows;
 	return 0;
 }
 
@@ -2094,6 +2096,7 @@
 		/* reset wrap/pan */
 		info->var.xoffset = info->var.yoffset = p->yscroll = 0;
 		p->vrows = info->var.yres_virtual / h;
+		p->vrows -= info->var.yres/h - vc->vc_rows;
 		if ((info->var.yres % h)
 		    && (info->var.yres_virtual % h < info->var.yres % h))
 			p->vrows--;



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> On Fri, 2003-03-07 at 23:19, Thomas Winischhofer wrote:
> 
>>This works - perfectly, I must say.
>>
>>However, the scrolling problem is still here, but I think I know the 
>>reason for this:
>>
>>Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
>>1024x768, using ypanning.
>>
>>This uses only 40*16=640 pixels vertically instead of the 768 available.
>>
>>The problem is the y panning, and is kind of both console's as well as 
>>the driver's fault:
>>
>>When the y panning area reaches its end, it's supposed to copy the 
>>screen to the beginning of this area and pan to position 0.
>>
>>However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.
>>
>>This disregards the fact that the visible screen area is actually larger 
>>than the area console is supposed to use.
> 
> 
> I've tested where the virtual window size is much smaller than the
> physical dimensions, and I do see the glitch you mentioned.  But it's
> mainly due to clear_margins().  clear_margins always erases a constant
> amount (physical_height - actual height).  So if you happen to pan just
> enough that there's not enough screen estate left, it will attempt to
> clear past yres_virtual.  Bad for drivers that do not implement
> clipping. Perhaps, block moves are involved here also, I'm not sure. 

1) Sisfb does no clipping, but there is plenty of video RAM past the 
virtual area.

2) I don't think we are talking about the same thing. Clear_margins() 
(which I haven't looked at, I confess) assumingly ... erm.. clears the 
margins. But why is it involved in scrolling any panning?

> So your patch has the correct idea, but here's a simpler one. It just
> reserves enough screen estate equal to difference of physical height and
> virtual height. I've tested this even using stty cols 2, and it works
> okay.

I don't see why this is simpler, but I do see it wastes a lot of screen 
space :)

BTW:

  	p->vrows = info->var.yres_virtual / vc->vc_font.height;
+	p->vrows -= info->var.yres - vc->vc_rows;

Look:

rows =          40
yres =         768
yres_v =      2048
font height =   16

vrows = 2048 / 16 = 128  (character unit)

128 - (768 - 40)

is negative...

Personally, I'd go with my first patch from earlier today. I tested this 
intensively in the meantime, and it Simpy Works(tm).

> NOTE:  Since we need var->yres, this time, we need to refer to info->var
> instead of the adjusted var.
> 
> BTW:  I've tested moving clear_margins before panning, it still doesn't
> remove the onrushing text past the virtual window height.  This would
> seem to need clipping to remove that eyesore.  

Honestly, I don't consider this important... But I thought you'd simply 
exchange the order of calling pan_var and drawing the characters... 
(which IMHO would be the correct order, logically speaking)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Fri, 2003-03-07 at 23:19, Thomas Winischhofer wrote:
> 
> This works - perfectly, I must say.
> 
> However, the scrolling problem is still here, but I think I know the 
> reason for this:
> 
> Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
> 1024x768, using ypanning.
> 
> This uses only 40*16=640 pixels vertically instead of the 768 available.
> 
> The problem is the y panning, and is kind of both console's as well as 
> the driver's fault:
> 
> When the y panning area reaches its end, it's supposed to copy the 
> screen to the beginning of this area and pan to position 0.
> 
> However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.
> 
> This disregards the fact that the visible screen area is actually larger 
> than the area console is supposed to use.

I've tested where the virtual window size is much smaller than the
physical dimensions, and I do see the glitch you mentioned.  But it's
mainly due to clear_margins().  clear_margins always erases a constant
amount (physical_height - actual height).  So if you happen to pan just
enough that there's not enough screen estate left, it will attempt to
clear past yres_virtual.  Bad for drivers that do not implement
clipping. Perhaps, block moves are involved here also, I'm not sure. 

So your patch has the correct idea, but here's a simpler one. It just
reserves enough screen estate equal to difference of physical height and
virtual height. I've tested this even using stty cols 2, and it works
okay.

NOTE:  Since we need var->yres, this time, we need to refer to info->var
instead of the adjusted var.

BTW:  I've tested moving clear_margins before panning, it still doesn't
remove the onrushing text past the virtual window height.  This would
seem to need clipping to remove that eyesore.  

If the patch doesn't apply cleanly, it should be easy enough to do so
manually.

Tony

diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-07 15:03:06.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-07 20:06:39.000000000 +0000
@@ -1044,6 +1044,7 @@
 		vc->vc_rows = nr_rows;
 	}
 	p->vrows = info->var.yres_virtual / vc->vc_font.height;
+	p->vrows -= info->var.yres - vc->vc_rows;
 	if ((info->var.yres % vc->vc_font.height) &&
 	    (info->var.yres_virtual % vc->vc_font.height <
 	     info->var.yres % vc->vc_font.height))
@@ -1821,8 +1822,9 @@
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
-		p->vrows = info->var.yres_virtual/fh;
 	}
+	p->vrows = info->var.yres_virtual/fh;
+	p->vrows -= (info->var.yres + (fh - 1))/fh - vc->vc_rows;
 	return 0;
 }
 
@@ -2094,6 +2096,7 @@
 		/* reset wrap/pan */
 		info->var.xoffset = info->var.yoffset = p->yscroll = 0;
 		p->vrows = info->var.yres_virtual / h;
+		p->vrows -= info->var.yres/h - vc->vc_rows;
 		if ((info->var.yres % h)
 		    && (info->var.yres_virtual % h < info->var.yres % h))
 			p->vrows--;





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Therefore, the calculation of vrows has to take the difference between
> these two into account.
>
> The attached patch fixes this for me but I have no idea if I cought all
> possible itches. It will no apply cleanly, because I had made changes to
> fbcon.c before making a backup copy - but it sure illustrates the problem.
>
> Why you used info->var.yres_virtual (and not the adapted
> var.yres_virtual) in fbcon_resize() is beyond me, BTW.

My mistake. I applied your patch.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Try this patch.  The fbcon_resize test is more liberal and it now correctly
> updates p->vrows and scroll_phys_max (for panning glitches).

Applied.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> On Fri, 7 Mar 2003, Thomas Winischhofer wrote:
> > Alright: I tested the newest fbdev patch.
> >
> > 1) Boot logo support: Does not compile, misses a script "p??tologo" or
> > anything like that.

??? That is getting annoying. Another patch is coming very soon.

P.S

   Almost done with porting matroxfb. Still some more to go tho.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
>>Therefore, the calculation of vrows has to take the difference between
>>these two into account.
>>
>>The attached patch fixes this for me but I have no idea if I cought all
>>possible itches. It will no apply cleanly, because I had made changes to
>>fbcon.c before making a backup copy - but it sure illustrates the problem.
>>
>>Why you used info->var.yres_virtual (and not the adapted
>>var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> 
> 
> My mistake. I applied your patch.

Reading first Toni's post (because it came one minute earlier) and now 
yours, what's true resp. correct now?

Thomas

PS: James, are you "entitled" to add maintainers to the MAINTAINERS 
file? I have actually been the maintainer of sisfb since a year back, so 
I think this should perhaps be mentioned..?

SIS FRAMEBUFFER DRIVER
P:	Thomas Winischhofer
M:	thomas@winischhofer.net
W:	http://www.winischhofer.net/linuxsisvga.shtml
S:	Maintained



-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Sat, 2003-03-08 at 01:00, Thomas Winischhofer wrote:
> >>Why you used info->var.yres_virtual (and not the adapted 
> >>var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> > 
> > Because info->var will _always_ contain the correct var, so we trust
> > that above all.
> 
> Then I must have misunderstood the code. You submit var (and not 
> info->var) to fb_set_var, so it is that var that will be treated by 
> check_var and used for set_par. Since check_var() may (and does) change 
> the yres_virtual according to the desired resolution/depth and so on, I 
> thought it might be more correct to use it instead of info->var...
> 

Note that fbcon_resize made a copy of info->var, then modified it
according to the requested width and height.  Then it goes through a
test if it needs an fb_set_var or not.  So info->var and the modified
var can be different if fb_set_var() wasn't called at all.  If it indeed
went through fb_set_var(), the var returned from check_var() will be
placed automatically to info->var before calling set_par().  So, yes, in
this case, info->var and the adjusted var will be the same.

Of course, in this particular code it is not important whichever var is
used because we're only interested in yres_virtual.  But using info->var
instead of the adjusted var is safer because it is guaranteed to be
always correct.

BTW: I'll check the patch against vesafb and let you know.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> Right, fbcon never dealt with margins greater than a character
> width/height before :-). I think your patch will do the Right Thing.

I hope so :) But please think it through, I have no idea about the 
possible impacts of this.

> As for the one you commented out as INCOMPLETE, my guess is it won't
> matter since that particular section of code is called only during
> initialization.  An fbcon_switch() will be called later on, I think.

No idea, but ... you're the expert!

>>Why you used info->var.yres_virtual (and not the adapted 
>>var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> 
> Because info->var will _always_ contain the correct var, so we trust
> that above all.

Then I must have misunderstood the code. You submit var (and not 
info->var) to fb_set_var, so it is that var that will be treated by 
check_var and used for set_par. Since check_var() may (and does) change 
the yres_virtual according to the desired resolution/depth and so on, I 
thought it might be more correct to use it instead of info->var...

I have in the meantime submitted a new sisfb patch to James; it depends, 
however, on the changes to fbcon we are discussing now (especially the 
fbcon_resize thing which is too intolerant in James' current code base). 
Otherwise, mode switches using stty won't work.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Fri, 2003-03-07 at 23:19, Thomas Winischhofer wrote:
> 
> This works - perfectly, I must say.
> 
> However, the scrolling problem is still here, but I think I know the 
> reason for this:
> 
> Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
> 1024x768, using ypanning.
> 
> This uses only 40*16=640 pixels vertically instead of the 768 available.
> 
> The problem is the y panning, and is kind of both console's as well as 
> the driver's fault:
> 
> When the y panning area reaches its end, it's supposed to copy the 
> screen to the beginning of this area and pan to position 0.
> 
> However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.
> 
> This disregards the fact that the visible screen area is actually larger 
> than the area console is supposed to use.
> 
> Therefore, the calculation of vrows has to take the difference between 
> these two into account.
> 
> The attached patch fixes this for me but I have no idea if I cought all 
> possible itches. It will no apply cleanly, because I had made changes to 
> fbcon.c before making a backup copy - but it sure illustrates the problem.
> 

Right, fbcon never dealt with margins greater than a character
width/height before :-). I think your patch will do the Right Thing.

As for the one you commented out as INCOMPLETE, my guess is it won't
matter since that particular section of code is called only during
initialization.  An fbcon_switch() will be called later on, I think.

> Why you used info->var.yres_virtual (and not the adapted 
> var.yres_virtual) in fbcon_resize() is beyond me, BTW.
> 

Because info->var will _always_ contain the correct var, so we trust
that above all.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

[-- Attachment #1: Type: text/plain, Size: 3889 bytes --]


This works - perfectly, I must say.

However, the scrolling problem is still here, but I think I know the 
reason for this:

Imagine a console of 120x40 (using the std 8x16 font), on a screen of 
1024x768, using ypanning.

This uses only 40*16=640 pixels vertically instead of the 768 available.

The problem is the y panning, and is kind of both console's as well as 
the driver's fault:

When the y panning area reaches its end, it's supposed to copy the 
screen to the beginning of this area and pan to position 0.

However, fbcon calculates p->vrows by info->var.yres_virtual / fontheight.

This disregards the fact that the visible screen area is actually larger 
than the area console is supposed to use.

Therefore, the calculation of vrows has to take the difference between 
these two into account.

The attached patch fixes this for me but I have no idea if I cought all 
possible itches. It will no apply cleanly, because I had made changes to 
fbcon.c before making a backup copy - but it sure illustrates the problem.

Why you used info->var.yres_virtual (and not the adapted 
var.yres_virtual) in fbcon_resize() is beyond me, BTW.

Thomas

Antonino Daplas wrote:
> On Fri, 2003-03-07 at 20:08, Thomas Winischhofer wrote:
> 
>>
>>However, there is still (at least) one problem within the console layer.
>>
>>With my patch, I can now have a console of for instance 128x20 
>>characters, on a 1024x768 screen. Scrolling mostly works, but sometimes 
>>console seems to forget to pan. I can't reproduce this on purpose, but 
>>printing eg. a directory with ls works in 90% of the cases (=scrolls 
>>correctly), but prints text beyond the current amount of rows in the 
>>remaining 10% of the cases. If I press enter until the last line of the 
>>console is on the very bottom of the 1024x768 screen, then it remembers 
>>its amount of rows and pans correctly.
>>
> 
> 
> Try this patch.  The fbcon_resize test is more liberal and it now correctly
> updates p->vrows and scroll_phys_max (for panning glitches).
> 
> Tony
> 
> 
> diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
> --- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-06 01:29:29.000000000 +0000
> +++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-07 13:54:04.000000000 +0000
> @@ -580,8 +580,8 @@
>  	struct fb_info *info = p->fb_info;
>  	unsigned int cw = vc->vc_font.width;
>  	unsigned int ch = vc->vc_font.height;
> -	unsigned int rw = info->var.xres % cw;
> -	unsigned int bh = info->var.yres % ch;
> +	unsigned int rw = info->var.xres - (cw * vc->vc_cols);
> +	unsigned int bh = info->var.yres - (ch * vc->vc_rows);
>  	unsigned int rs = info->var.xres - rw;
>  	unsigned int bs = info->var.yres - bh;
>  	struct fb_fillrect region;
> @@ -1815,14 +1815,14 @@
>  	   (y_diff < 0 || y_diff > fh)) {
>  		var.activate = FB_ACTIVATE_TEST;
>  		err = fb_set_var(&var, info);
> -		if (err || width != var.xres/fw ||
> -		    height != var.yres/fh)
> +		if (err || width > var.xres/fw ||
> +		    height > var.yres/fh)
>  			return -EINVAL;
>  		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
>  		var.activate = FB_ACTIVATE_NOW;
>  		fb_set_var(&var, info);
> -		p->vrows = info->var.yres_virtual/fh;
>  	}
> +	p->vrows = info->var.yres_virtual/fh;
>  	return 0;
>  }
>  
> @@ -1857,6 +1857,7 @@
>  	}
>  	if (info)
>  		info->var.yoffset = p->yscroll = 0;
> +        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
>  	switch (p->scrollmode & __SCROLL_YMASK) {
>  	case __SCROLL_YWRAP:
>  		scrollback_phys_max = p->vrows - vc->vc_rows;
> @@ -1875,7 +1876,6 @@
>  
>  	info->currcon = unit;
>  	
> -        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
>  	update_var(unit, info);
>  	fbcon_set_palette(vc, color_table); 	
>  
> 
> 


-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/



[-- Attachment #2: fbcon_patch --]
[-- Type: application/x-java-applet, Size: 1373 bytes --]

Re: Some questions

[Antonino Daplas]

On Fri, 2003-03-07 at 20:08, Thomas Winischhofer wrote:
> 
> 
> However, there is still (at least) one problem within the console layer.
> 
> With my patch, I can now have a console of for instance 128x20 
> characters, on a 1024x768 screen. Scrolling mostly works, but sometimes 
> console seems to forget to pan. I can't reproduce this on purpose, but 
> printing eg. a directory with ls works in 90% of the cases (=scrolls 
> correctly), but prints text beyond the current amount of rows in the 
> remaining 10% of the cases. If I press enter until the last line of the 
> console is on the very bottom of the 1024x768 screen, then it remembers 
> its amount of rows and pans correctly.
>

Try this patch.  The fbcon_resize test is more liberal and it now correctly
updates p->vrows and scroll_phys_max (for panning glitches).

Tony


diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c	2003-03-06 01:29:29.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c	2003-03-07 13:54:04.000000000 +0000
@@ -580,8 +580,8 @@
 	struct fb_info *info = p->fb_info;
 	unsigned int cw = vc->vc_font.width;
 	unsigned int ch = vc->vc_font.height;
-	unsigned int rw = info->var.xres % cw;
-	unsigned int bh = info->var.yres % ch;
+	unsigned int rw = info->var.xres - (cw * vc->vc_cols);
+	unsigned int bh = info->var.yres - (ch * vc->vc_rows);
 	unsigned int rs = info->var.xres - rw;
 	unsigned int bs = info->var.yres - bh;
 	struct fb_fillrect region;
@@ -1815,14 +1815,14 @@
 	   (y_diff < 0 || y_diff > fh)) {
 		var.activate = FB_ACTIVATE_TEST;
 		err = fb_set_var(&var, info);
-		if (err || width != var.xres/fw ||
-		    height != var.yres/fh)
+		if (err || width > var.xres/fw ||
+		    height > var.yres/fh)
 			return -EINVAL;
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
 		fb_set_var(&var, info);
-		p->vrows = info->var.yres_virtual/fh;
 	}
+	p->vrows = info->var.yres_virtual/fh;
 	return 0;
 }
 
@@ -1857,6 +1857,7 @@
 	}
 	if (info)
 		info->var.yoffset = p->yscroll = 0;
+        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
 	switch (p->scrollmode & __SCROLL_YMASK) {
 	case __SCROLL_YWRAP:
 		scrollback_phys_max = p->vrows - vc->vc_rows;
@@ -1875,7 +1876,6 @@
 
 	info->currcon = unit;
 	
-        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
 	update_var(unit, info);
 	fbcon_set_palette(vc, color_table); 	
 




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Fri, 7 Mar 2003, Thomas Winischhofer wrote:
> Alright: I tested the newest fbdev patch.
> 
> 1) Boot logo support: Does not compile, misses a script "p??tologo" or 
> anything like that.

--- linux-2.5.64/scripts/Makefile	Wed Mar  5 10:07:45 2003
+++ linux-logo-2.5.64/scripts/Makefile	Wed Mar  5 13:19:54 2003
@@ -9,7 +9,7 @@
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
 host-progs    := fixdep split-include conmakehash docproc kallsyms modpost \
-		 mk_elfconfig
+		 mk_elfconfig pnmtologo
 build-targets := $(host-progs) empty.o
 
 modpost-objs  := modpost.o file2alias.o
--- linux-2.5.64/scripts/pnmtologo.c	Thu Jan  1 01:00:00 1970
+++ linux-logo-2.5.64/scripts/pnmtologo.c	Fri Jan 24 17:19:33 2003
@@ -0,0 +1,507 @@
+
+/*
+ *  Convert a logo in ASCII PNM format to C source suitable for inclusion in
+ *  the Linux kernel
+ *
+ *  (C) Copyright 2001-2003 by Geert Uytterhoeven <geert@linux-m68k.org>
+ *
+ *  --------------------------------------------------------------------------
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License. See the file COPYING in the main directory of the Linux
+ *  distribution for more details.
+ */
+
+#include <ctype.h>
+#include <errno.h>
+#include <stdarg.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+
+static const char *programname;
+static const char *filename;
+static const char *logoname = "linux_logo";
+static const char *outputname;
+static FILE *out;
+
+
+#define LINUX_LOGO_MONO		1	/* monochrome black/white */
+#define LINUX_LOGO_VGA16	2	/* 16 colors VGA text palette */
+#define LINUX_LOGO_CLUT224	3	/* 224 colors */
+#define LINUX_LOGO_GRAY256	4	/* 256 levels grayscale */
+
+static const char *logo_types[LINUX_LOGO_GRAY256+1] = {
+    [LINUX_LOGO_MONO] = "LINUX_LOGO_MONO",
+    [LINUX_LOGO_VGA16] = "LINUX_LOGO_VGA16",
+    [LINUX_LOGO_CLUT224] = "LINUX_LOGO_CLUT224",
+    [LINUX_LOGO_GRAY256] = "LINUX_LOGO_GRAY256"
+};
+
+#define MAX_LINUX_LOGO_COLORS	224
+
+struct color {
+    unsigned char red;
+    unsigned char green;
+    unsigned char blue;
+};
+
+static const struct color clut_vga16[16] = {
+    { 0x00, 0x00, 0x00 },
+    { 0x00, 0x00, 0xaa },
+    { 0x00, 0xaa, 0x00 },
+    { 0x00, 0xaa, 0xaa },
+    { 0xaa, 0x00, 0x00 },
+    { 0xaa, 0x00, 0xaa },
+    { 0xaa, 0x55, 0x00 },
+    { 0xaa, 0xaa, 0xaa },
+    { 0x55, 0x55, 0x55 },
+    { 0x55, 0x55, 0xff },
+    { 0x55, 0xff, 0x55 },
+    { 0x55, 0xff, 0xff },
+    { 0xff, 0x55, 0x55 },
+    { 0xff, 0x55, 0xff },
+    { 0xff, 0xff, 0x55 },
+    { 0xff, 0xff, 0xff },
+};
+
+
+static int logo_type = LINUX_LOGO_CLUT224;
+static unsigned int logo_width;
+static unsigned int logo_height;
+static struct color **logo_data;
+static struct color logo_clut[MAX_LINUX_LOGO_COLORS];
+static unsigned int logo_clutsize = 0;
+
+static void die(const char *fmt, ...)
+    __attribute__ ((noreturn)) __attribute ((format (printf, 1, 2)));
+static void usage(void) __attribute ((noreturn));
+
+
+static unsigned int get_number(FILE *fp)
+{
+    int c, val;
+
+    /* Skip leading whitespace */
+    do {
+	c = fgetc(fp);
+	if (c == EOF)
+	    die("%s: end of file\n", filename);
+	if (c == '#') {
+	    /* Ignore comments 'till end of line */
+	    do {
+		c = fgetc(fp);
+		if (c == EOF)
+		    die("%s: end of file\n", filename);
+	    } while (c != '\n');
+	}
+    } while (isspace(c));
+
+    /* Parse decimal number */
+    val = 0;
+    while (isdigit(c)) {
+	val = 10*val+c-'0';
+	c = fgetc(fp);
+	if (c == EOF)
+	    die("%s: end of file\n", filename);
+    }
+    return val;
+}
+
+static unsigned int get_number255(FILE *fp, unsigned int maxval)
+{
+    unsigned int val = get_number(fp);
+    return (255*val+maxval/2)/maxval;
+}
+
+static void read_image(void)
+{
+    FILE *fp;
+    int i, j, magic;
+    unsigned int maxval;
+
+    /* open image file */
+    fp = fopen(filename, "r");
+    if (!fp)
+	die("Cannot open file %s: %s\n", filename, strerror(errno));
+
+    /* check file type and read file header */
+    magic = fgetc(fp);
+    if (magic != 'P')
+	die("%s is not a PNM file\n", filename);
+    magic = fgetc(fp);
+    switch (magic) {
+	case '1':
+	case '2':
+	case '3':
+	    /* Plain PBM/PGM/PPM */
+	    break;
+
+	case '4':
+	case '5':
+	case '6':
+	    /* Binary PBM/PGM/PPM */
+	    die("%s: Binary PNM is not supported\n"
+		"Use pnmnoraw(1) to convert it to ASCII PNM\n", filename);
+
+	default:
+	    die("%s is not a PNM file\n", filename);
+    }
+    logo_width = get_number(fp);
+    logo_height = get_number(fp);
+
+    /* allocate image data */
+    logo_data = (struct color **)malloc(logo_height*sizeof(struct color *));
+    if (!logo_data)
+	die("%s\n", strerror(errno));
+    for (i = 0; i < logo_height; i++) {
+	logo_data[i] = malloc(logo_width*sizeof(struct color));
+	if (!logo_data[i])
+	    die("%s\n", strerror(errno));
+    }
+
+    /* read image data */
+    switch (magic) {
+	case '1':
+	    /* Plain PBM */
+	    for (i = 0; i < logo_height; i++)
+		for (j = 0; j < logo_width; j++)
+		    logo_data[i][j].red = logo_data[i][j].green =
+			logo_data[i][j].blue = 255*(1-get_number(fp));
+	    break;
+
+	case '2':
+	    /* Plain PGM */
+	    maxval = get_number(fp);
+	    for (i = 0; i < logo_height; i++)
+		for (j = 0; j < logo_width; j++)
+		    logo_data[i][j].red = logo_data[i][j].green =
+			logo_data[i][j].blue = get_number255(fp, maxval);
+	    break;
+
+	case '3':
+	    /* Plain PPM */
+	    maxval = get_number(fp);
+	    for (i = 0; i < logo_height; i++)
+		for (j = 0; j < logo_width; j++) {
+		    logo_data[i][j].red = get_number255(fp, maxval);
+		    logo_data[i][j].green = get_number255(fp, maxval);
+		    logo_data[i][j].blue = get_number255(fp, maxval);
+		}
+	    break;
+    }
+
+    /* close file */
+    fclose(fp);
+}
+
+static inline int is_black(struct color c)
+{
+    return c.red == 0 && c.green == 0 && c.blue == 0;
+}
+
+static inline int is_white(struct color c)
+{
+    return c.red == 255 && c.green == 255 && c.blue == 255;
+}
+
+static inline int is_gray(struct color c)
+{
+    return c.red == c.green && c.red == c.blue;
+}
+
+static inline int is_equal(struct color c1, struct color c2)
+{
+    return c1.red == c2.red && c1.green == c2.green && c1.blue == c2.blue;
+}
+
+static void write_header(void)
+{
+    /* open logo file */
+    if (outputname) {
+	out = fopen(outputname, "w");
+	if (!out)
+	    die("Cannot create file %s: %s\n", outputname, strerror(errno));
+    } else {
+	out = stdout;
+    }
+
+    fputs("/*\n", out);
+    fputs(" *  DO NOT EDIT THIS FILE!\n", out);
+    fputs(" *\n", out);
+    fprintf(out, " *  It was automatically generated from %s\n", filename);
+    fputs(" *\n", out);
+    fprintf(out, " *  Linux logo %s\n", logoname);
+    fputs(" */\n\n", out);
+    fputs("#include <linux/linux_logo.h>\n\n", out);
+    fprintf(out, "static const unsigned char %s_data[] __initdata = {\n",
+	    logoname);
+}
+
+static void write_footer(void)
+{
+    fputs("\n};\n\n", out);
+    fprintf(out, "const struct linux_logo %s __initdata = {\n", logoname);
+    fprintf(out, "    .type\t= %s,\n", logo_types[logo_type]);
+    fprintf(out, "    .width\t= %d,\n", logo_width);
+    fprintf(out, "    .height\t= %d,\n", logo_height);
+    if (logo_type == LINUX_LOGO_CLUT224) {
+	fprintf(out, "    .clutsize\t= %d,\n", logo_clutsize);
+	fprintf(out, "    .clut\t= %s_clut,\n", logoname);
+    }
+    fprintf(out, "    .data\t= %s_data\n", logoname);
+    fputs("};\n\n", out);
+
+    /* close logo file */
+    if (outputname)
+	fclose(out);
+}
+
+static int write_hex_cnt = 0;
+
+static void write_hex(unsigned char byte)
+{
+    if (write_hex_cnt % 12)
+	fprintf(out, ", 0x%02x", byte);
+    else if (write_hex_cnt)
+	fprintf(out, ",\n\t0x%02x", byte);
+    else
+	fprintf(out, "\t0x%02x", byte);
+    write_hex_cnt++;
+}
+
+static void write_logo_mono(void)
+{
+    int i, j;
+    unsigned char val, bit;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++)
+	    if (!is_black(logo_data[i][j]) && !is_white(logo_data[i][j]))
+		die("Image must be monochrome\n");
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++) {
+	for (j = 0; j < logo_width;) {
+	    for (val = 0, bit = 0x80; bit && j < logo_width; j++, bit >>= 1)
+		if (logo_data[i][j].red)
+		    val |= bit;
+	    write_hex(val);
+	}
+    }
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void write_logo_vga16(void)
+{
+    int i, j, k;
+    unsigned char val;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < 16; k++)
+		if (is_equal(logo_data[i][j], clut_vga16[k]))
+		    break;
+	    if (k == 16)
+		die("Image must use the 16 console colors only\n"
+		    "Use ppmquant(1) -map clut_vga16.ppm to reduce the number "
+		    "of colors\n");
+	}
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < 16; k++)
+		if (is_equal(logo_data[i][j], clut_vga16[k]))
+		    break;
+	    val = k<<4;
+	    if (++j < logo_width) {
+		for (k = 0; k < 16; k++)
+		    if (is_equal(logo_data[i][j], clut_vga16[k]))
+			break;
+		val |= k;
+	    }
+	    write_hex(val);
+	}
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void write_logo_clut224(void)
+{
+    int i, j, k;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < logo_clutsize; k++)
+		if (is_equal(logo_data[i][j], logo_clut[k]))
+		    break;
+	    if (k == logo_clutsize) {
+		if (logo_clutsize == MAX_LINUX_LOGO_COLORS)
+		    die("Image has more than %d colors\n"
+			"Use ppmquant(1) to reduce the number of colors\n",
+			MAX_LINUX_LOGO_COLORS);
+		logo_clut[logo_clutsize++] = logo_data[i][j];
+	    }
+	}
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++) {
+	    for (k = 0; k < logo_clutsize; k++)
+		if (is_equal(logo_data[i][j], logo_clut[k]))
+		    break;
+	    write_hex(k+32);
+	}
+    fputs("\n};\n\n", out);
+
+    /* write logo clut */
+    fprintf(out, "static const unsigned char %s_clut[] __initdata = {\n",
+	    logoname);
+    write_hex_cnt = 0;
+    for (i = 0; i < logo_clutsize; i++) {
+	write_hex(logo_clut[i].red);
+	write_hex(logo_clut[i].green);
+	write_hex(logo_clut[i].blue);
+    }
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void write_logo_gray256(void)
+{
+    int i, j;
+
+    /* validate image */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++)
+	    if (!is_gray(logo_data[i][j]))
+		die("Image must be grayscale\n");
+
+    /* write file header */
+    write_header();
+
+    /* write logo data */
+    for (i = 0; i < logo_height; i++)
+	for (j = 0; j < logo_width; j++)
+	    write_hex(logo_data[i][j].red);
+
+    /* write logo structure and file footer */
+    write_footer();
+}
+
+static void die(const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vfprintf(stderr, fmt, ap);
+    va_end(ap);
+
+    exit(1);
+}
+
+static void usage(void)
+{
+    die("\n"
+	"Usage: %s [options] <filename>\n"
+	"\n"
+	"Valid options:\n"
+	"    -h          : display this usage information\n"
+	"    -n <name>   : specify logo name (default: linux_logo)\n"
+	"    -o <output> : output to file <output> instead of stdout\n"
+	"    -t <type>   : specify logo type, one of\n"
+	"                      mono    : monochrome black/white\n"
+	"                      vga16   : 16 colors VGA text palette\n"
+	"                      clut224 : 224 colors (default)\n"
+	"                      gray256 : 256 levels grayscale\n"
+	"\n", programname);
+}
+
+int main(int argc, char *argv[])
+{
+    int opt;
+
+    programname = argv[0];
+
+    opterr = 0;
+    while (1) {
+	opt = getopt(argc, argv, "hn:o:t:");
+	if (opt == -1)
+	    break;
+
+	switch (opt) {
+	    case 'h':
+		usage();
+		break;
+
+	    case 'n':
+		logoname = optarg;
+		break;
+
+	    case 'o':
+		outputname = optarg;
+		break;
+
+	    case 't':
+		if (!strcmp(optarg, "mono"))
+		    logo_type = LINUX_LOGO_MONO;
+		else if (!strcmp(optarg, "vga16"))
+		    logo_type = LINUX_LOGO_VGA16;
+		else if (!strcmp(optarg, "clut224"))
+		    logo_type = LINUX_LOGO_CLUT224;
+		else if (!strcmp(optarg, "gray256"))
+		    logo_type = LINUX_LOGO_GRAY256;
+		else
+		    usage();
+		break;
+
+	    default:
+		usage();
+		break;
+	}
+    }
+    if (optind != argc-1)
+	usage();
+
+    filename = argv[optind];
+
+    read_image();
+    switch (logo_type) {
+	case LINUX_LOGO_MONO:
+	    write_logo_mono();
+	    break;
+
+	case LINUX_LOGO_VGA16:
+	    write_logo_vga16();
+	    break;
+
+	case LINUX_LOGO_CLUT224:
+	    write_logo_clut224();
+	    break;
+
+	case LINUX_LOGO_GRAY256:
+	    write_logo_gray256();
+	    break;
+    }
+    exit(0);
+}
+

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Alright: I tested the newest fbdev patch.

1) Boot logo support: Does not compile, misses a script "p??tologo" or 
anything like that.

2) Changed sisfb to accept practically any mode, but it now adapts to 
the next larger supported mode if no exact mode based on rows and cols 
is found. Previously, this adaption was limited to 16 pixels.

stty does not work at all now, because fbcon's fbcon_resize() checks the 
returned var from fb_set_var if the mode is off more than one character 
in height and width - and returns EINVAL in this case.

Since stty calles the console code twice if rows and cols are provided, 
this fails miserably, because the first attempt (which for example 
requests 800x768 if switching from 1024x768 to 800x600) fails.

So I changed fbcon from

	if(err || width != var.xres/fw || height != var.yres/fh)

to

	if(err)

and now it works.

However, there is still (at least) one problem within the console layer.

With my patch, I can now have a console of for instance 128x20 
characters, on a 1024x768 screen. Scrolling mostly works, but sometimes 
console seems to forget to pan. I can't reproduce this on purpose, but 
printing eg. a directory with ls works in 90% of the cases (=scrolls 
correctly), but prints text beyond the current amount of rows in the 
remaining 10% of the cases. If I press enter until the last line of the 
console is on the very bottom of the 1024x768 screen, then it remembers 
its amount of rows and pans correctly.

For estethical reasons, I would also recommend changing the order or 
panning and character drawing. Now, the characters seem to be drawn 
first, and panning is done later. That causes some flickering sometimes, 
and with a console smaller than the screen resolution (eg. screen is 
1024x768, console uses only 20 rows), text is shown below the 20th row 
for a fraction of a second before the panning is done.

I will send the current sisfb code to James later today. (It also fixes
some non-fbdev-related mode switching problems on some Asus laptops)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > 
> > And if you use very narrow vsync and hsync ranges, then the "stale"
> > pixelclock will always most certainly be invalid.
> 
> BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> which is attached to the card (or even a TV) ? I think the radeonfb
> knows how to do this, not sure though.

Not that I know of.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > Oops, totally missed your question :-)  But yes, I think the EDID block
> > contains information about the monitor type, not sure thogh.
> 
> X finds :
> 
> Digital Display Input
> 
> So, i guess this is it.

Yes the EDID block does have info on the monitor type. It even has the 
vendor name. I wonder if it can detect when you unplug a monitor and plug 
in a new one?



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 19:40, Sven Luther wrote:
> > > 
> > > There's an EDID parser in fbmon.c.  I think it will work only for the
> > > PPC. This is currently used by rivafb and radeonfb. For the rest, either
> 
> Mmm, is it because the EDID parser uses the EDID information pased by
> the OF ?
> 

Yes.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Sven Luther]

On Thu, Mar 06, 2003 at 06:51:58PM +0800, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote:
> > On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> > > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > > > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > > > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > > > any fall outside, the entire mode, pixelclock and all is not valid.
> > > > 
> > > > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > > > 
> > > > And if you use very narrow vsync and hsync ranges, then the "stale"
> > > > pixelclock will always most certainly be invalid.
> > > 
> > > BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> > > which is attached to the card (or even a TV) ? I think the radeonfb
> > > knows how to do this, not sure though.
> > > 
> > 
> > There's an EDID parser in fbmon.c.  I think it will work only for the
> > PPC. This is currently used by rivafb and radeonfb. For the rest, either

Mmm, is it because the EDID parser uses the EDID information pased by
the OF ?

> > we implement DDC or just have something similar to XF86Config's
> > HorizSync and VertRefresh.  We can load this either as a kernel/module
> > option or passed via ioctl/sysfs.  

Most monitors today have DDC support, so i guess best would be to use
it, and fall back to a command line option if DDC is not supported.

> > I'm already doing this with the i810fb (as boot/module option), which
> > greatly simplified mode switching.
> 
> Oops, totally missed your question :-)  But yes, I think the EDID block
> contains information about the monitor type, not sure thogh.

X finds :

Digital Display Input

So, i guess this is it.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > > any fall outside, the entire mode, pixelclock and all is not valid.
> > > 
> > > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > > 
> > > And if you use very narrow vsync and hsync ranges, then the "stale"
> > > pixelclock will always most certainly be invalid.
> > 
> > BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> > which is attached to the card (or even a TV) ? I think the radeonfb
> > knows how to do this, not sure though.
> > 
> 
> There's an EDID parser in fbmon.c.  I think it will work only for the
> PPC. This is currently used by rivafb and radeonfb. For the rest, either
> we implement DDC or just have something similar to XF86Config's
> HorizSync and VertRefresh.  We can load this either as a kernel/module
> option or passed via ioctl/sysfs.  
> 
> I'm already doing this with the i810fb (as boot/module option), which
> greatly simplified mode switching.
> 

Oops, totally missed your question :-)  But yes, I think the EDID block
contains information about the monitor type, not sure thogh.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 18:31, Sven Luther wrote:
> On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> > Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> > calculate hsync and vsync.  Compare this with your monitor's limit -- if
> > any fall outside, the entire mode, pixelclock and all is not valid.
> > 
> > (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> > 
> > And if you use very narrow vsync and hsync ranges, then the "stale"
> > pixelclock will always most certainly be invalid.
> 
> BTW, do we have an easy way of knowing if it is an LCD or analog monitor
> which is attached to the card (or even a TV) ? I think the radeonfb
> knows how to do this, not sure though.
> 

There's an EDID parser in fbmon.c.  I think it will work only for the
PPC. This is currently used by rivafb and radeonfb. For the rest, either
we implement DDC or just have something similar to XF86Config's
HorizSync and VertRefresh.  We can load this either as a kernel/module
option or passed via ioctl/sysfs.  

I'm already doing this with the i810fb (as boot/module option), which
greatly simplified mode switching.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Sven Luther]

On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote:
> Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
> calculate hsync and vsync.  Compare this with your monitor's limit -- if
> any fall outside, the entire mode, pixelclock and all is not valid.
> 
> (see fb_get_mode() and fb_validate_mode() in fbmon.c)
> 
> And if you use very narrow vsync and hsync ranges, then the "stale"
> pixelclock will always most certainly be invalid.

BTW, do we have an easy way of knowing if it is an LCD or analog monitor
which is attached to the card (or even a TV) ? I think the radeonfb
knows how to do this, not sure though.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 18:14, Geert Uytterhoeven wrote:
> On 6 Mar 2003, Antonino Daplas wrote:
> > On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> > > What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> > > current resolution?
> > > 
> > > If you use stty to change the number of cols/rows, or change the font, or use
> > > fbset, your text console may end up being smaller or larger than the real
> > > screen size, in which case margins are cleared, or columns/lines are lost.
> > > (Optionally, we can center the text console if it's smaller than the real
> > >  screen size.)
> > > 
> > 
> > Which is basically what stty does for the standard console (except that
> > lines are not lost, but wrapped, and margins are not cleared).
> > 
> > So, we need to reimplement the clipping code.
> 
> In fbcon, I hope?
> 

Yes, it's easier to do this in fbcon.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On 6 Mar 2003, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> > What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> > current resolution?
> > 
> > If you use stty to change the number of cols/rows, or change the font, or use
> > fbset, your text console may end up being smaller or larger than the real
> > screen size, in which case margins are cleared, or columns/lines are lost.
> > (Optionally, we can center the text console if it's smaller than the real
> >  screen size.)
> > 
> 
> Which is basically what stty does for the standard console (except that
> lines are not lost, but wrapped, and margins are not cleared).
> 
> So, we need to reimplement the clipping code.

In fbcon, I hope?

> > IMHO this is the most orthogonal approach. Fbcon takes care of the text
> > console, fbdev takes care of the graphics hardware and the video mode. Both
> > parts do (try to) not influence each other.
> > 
> > Optionally, fbset can call stty to change the number of cols/rows, if the user
> > wants that.
> 
> Or even a simple script that basically does "fbset 1024x768-60 && stty
> cols 128 rows 48". Of course, adding this to fbset itself will make it
> transparent to the user.
> 
> Sounds very logical to me :-)

Yep ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 17:43, Thomas Winischhofer wrote:
> > Mode checking is not simply looking at xres and yres, but also looking
> > at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> > then compared to the monitor/graphics card's capability.  If any of the
> > values fall outside the limits then the mode is not valid.  Otherwise,
> > the new mode should still produce a usable display, perhaps not the one
> > the user wants (ie refresh rate is lower).  By this time though, the
> > user can freely use fbset to fine tune all the timings.
> 
> Perhaps I have not made myself clear:
> 
> I start with a default 800x600-60. Pixelclock in var is now X.
> 
> fbcon_resize adapts the xres and yres, leaving the pixelclock alone.
> 
> The driver sees upon the check_var call: xres, yres and X - the old 
> pixelclock (which is non-zero).
> 
> That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
> no way of distinguishing!
> 

Yes, there is.  Using the "stale" pixelclock, htotal and vtotal,
calculate hsync and vsync.  Compare this with your monitor's limit -- if
any fall outside, the entire mode, pixelclock and all is not valid.

(see fb_get_mode() and fb_validate_mode() in fbmon.c)

And if you use very narrow vsync and hsync ranges, then the "stale"
pixelclock will always most certainly be invalid.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 17:12, Geert Uytterhoeven wrote:
> 
> What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
> current resolution?
> 
> If you use stty to change the number of cols/rows, or change the font, or use
> fbset, your text console may end up being smaller or larger than the real
> screen size, in which case margins are cleared, or columns/lines are lost.
> (Optionally, we can center the text console if it's smaller than the real
>  screen size.)
> 

Which is basically what stty does for the standard console (except that
lines are not lost, but wrapped, and margins are not cleared).

So, we need to reimplement the clipping code.

> IMHO this is the most orthogonal approach. Fbcon takes care of the text
> console, fbdev takes care of the graphics hardware and the video mode. Both
> parts do (try to) not influence each other.
> 
> Optionally, fbset can call stty to change the number of cols/rows, if the user
> wants that.
> 

Or even a simple script that basically does "fbset 1024x768-60 && stty
cols 128 rows 48". Of course, adding this to fbset itself will make it
transparent to the user.

Sounds very logical to me :-)

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> On Thu, 2003-03-06 at 16:49, Thomas Winischhofer wrote:
>>>However, the brokenness is really on the driver side.  They are unable
>>>to change the video mode unless they are supplied with the correct
>>>timing parameters where in fact they actually have the best knowledge on
>>>how to calculate them.  
>>
>>Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
>>requires at least x and y dimension AND A CLOCK (or a vertical refresh 
>>rate, which I would prefer).
> 
> The VESA GTF can calculate timings using only xres, yres and any of the
> three...
> 
> 1. desired pixelclock
> 2. desired refresh
> 3. desired hsync
> 
> ... all of which can be chosen by the driver, or extracted from the monitor
> (ie. DDC or uploaded by the user).

See? Need a clock! My word! :)

> Mode checking is not simply looking at xres and yres, but also looking
> at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
> then compared to the monitor/graphics card's capability.  If any of the
> values fall outside the limits then the mode is not valid.  Otherwise,
> the new mode should still produce a usable display, perhaps not the one
> the user wants (ie refresh rate is lower).  By this time though, the
> user can freely use fbset to fine tune all the timings.

Perhaps I have not made myself clear:

I start with a default 800x600-60. Pixelclock in var is now X.

fbcon_resize adapts the xres and yres, leaving the pixelclock alone.

The driver sees upon the check_var call: xres, yres and X - the old 
pixelclock (which is non-zero).

That pixelclock *COULD* be valid, but it COULD also be invalid! There is 
no way of distinguishing!

>>What about the following solution: What if fbcon_resize sets the clock 
>>in the var to 0? We could use this to force low level drivers to decide 
>>on the clock for themselves. Otherwise, ie if the clock field is 
>>non-zero, they are supposed to take it as the desired clock.
> 
> Yes, that's another solution.  Just invalidate the timings and force the
> driver to compute a modeline each time.

I think Geert came up with a better solution in the meantime.

But a general rule should be anyway: Whenever passing a var to the 
driver which only changed in a few fields and through this invalidated 
the timing settings, the caller should set everthing else to ZERO, in 
other words: invalidate it in a recognizable way. That's IMHO the only 
way the driver can distinguish between intended and unintended settings.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 16:49, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > fbcon_resize() is not that broken, it's only trying to do what it's
> > supposed to do.  It is indeed limited because it is trying to outguess
> > the low-level drivers on the best resolution for a window size.
> > 
> > However, the brokenness is really on the driver side.  They are unable
> > to change the video mode unless they are supplied with the correct
> > timing parameters where in fact they actually have the best knowledge on
> > how to calculate them.  
> 
> Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
> requires at least x and y dimension AND A CLOCK (or a vertical refresh 
> rate, which I would prefer).

The VESA GTF can calculate timings using only xres, yres and any of the
three...

1. desired pixelclock
2. desired refresh
3. desired hsync

... all of which can be chosen by the driver, or extracted from the monitor
(ie. DDC or uploaded by the user).

For non-GTF compatible monitors, you can choose any of the standard timings
table. 

> 
> The driver is supposed to handle the "var"s it's fed. If that var is 
> like the ones that result from the current fbcon_resize, namely with a 
> new x and y res, but no valid clock, how on earth should the driver do 
> this then? It receives a var which looks correct, and in fact, *could* 
> be correct sometimes:
> 

Mode checking is not simply looking at xres and yres, but also looking
at htotal, and vtotal to derive hsync, vsync and pixelclock.  These are
then compared to the monitor/graphics card's capability.  If any of the
values fall outside the limits then the mode is not valid.  Otherwise,
the new mode should still produce a usable display, perhaps not the one
the user wants (ie refresh rate is lower).  By this time though, the
user can freely use fbset to fine tune all the timings.

For fixed-frequency monitors or analog TV (where timings are critical),
you can use very strict operating limits (like vsync_min = 60 and
vsync_max = 60).  With strict limits, it's unlikely that the new timings
will be valid, so the driver will always be forced to calculate a new
mode.

> Suppose we have another application, say DirectFB, feeding the low level 
> drivers with complete and correct "var"s.
> 
> In both cases we have valid x any y resultions, and a non-zero clock field.
> 
> Should we then let the driver read the x and y resolution and forget 
> about the rest of that var? I hardly think that's what the public var is 
> for. It could be reduced to a struct { USHORT xres, USHORT yres } then.
> 
> > So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> > we let the drivers calculate it for themselves?  I go for the latter, as
> > fbcon really should not have any business with hardware.
> 
> What about the following solution: What if fbcon_resize sets the clock 
> in the var to 0? We could use this to force low level drivers to decide 
> on the clock for themselves. Otherwise, ie if the clock field is 
> non-zero, they are supposed to take it as the desired clock.
> 

Yes, that's another solution.  Just invalidate the timings and force the
driver to compute a modeline each time.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Thu, 6 Mar 2003, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> > fbcon_resize() is not that broken, it's only trying to do what it's
> > supposed to do.  It is indeed limited because it is trying to outguess
> > the low-level drivers on the best resolution for a window size.
> > 
> > However, the brokenness is really on the driver side.  They are unable
> > to change the video mode unless they are supplied with the correct
> > timing parameters where in fact they actually have the best knowledge on
> > how to calculate them.  
> 
> Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
> requires at least x and y dimension AND A CLOCK (or a vertical refresh 
> rate, which I would prefer).
> 
> The driver is supposed to handle the "var"s it's fed. If that var is 
> like the ones that result from the current fbcon_resize, namely with a 
> new x and y res, but no valid clock, how on earth should the driver do 
> this then? It receives a var which looks correct, and in fact, *could* 
> be correct sometimes:
> 
> Suppose we have another application, say DirectFB, feeding the low level 
> drivers with complete and correct "var"s.
> 
> In both cases we have valid x any y resultions, and a non-zero clock field.
> 
> Should we then let the driver read the x and y resolution and forget 
> about the rest of that var? I hardly think that's what the public var is 
> for. It could be reduced to a struct { USHORT xres, USHORT yres } then.
> 
> > So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> > we let the drivers calculate it for themselves?  I go for the latter, as
> > fbcon really should not have any business with hardware.
> 
> What about the following solution: What if fbcon_resize sets the clock 
> in the var to 0? We could use this to force low level drivers to decide 
> on the clock for themselves. Otherwise, ie if the clock field is 
> non-zero, they are supposed to take it as the desired clock.

What if fbcon implements a text console _on top of_ fbdev? I.e. it uses the
current resolution?

If you use stty to change the number of cols/rows, or change the font, or use
fbset, your text console may end up being smaller or larger than the real
screen size, in which case margins are cleared, or columns/lines are lost.
(Optionally, we can center the text console if it's smaller than the real
 screen size.)

IMHO this is the most orthogonal approach. Fbcon takes care of the text
console, fbdev takes care of the graphics hardware and the video mode. Both
parts do (try to) not influence each other.

Optionally, fbset can call stty to change the number of cols/rows, if the user
wants that.

What do you think?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 16:33, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, James Simmons wrote:
> > > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > > Now if you think about it we can do things like change the bpp without 
> > > > having to redo the monitor programming. This is the flaw with the old and 
> > > > even the new api. 
> > > 
> > > You could have done that from the beginning. Just look at which fields have
> > > changed and which haven't.
> > 
> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One other reason why this isn't done is because X may interfere with it. If we
> don't do a full register update, but change the parts that need a change only,
> we will see less flickering (no PLL reprogramming), but we will suffer if X
> doesn't restore the registers to the exact same values they were before.
> 

Ideally, that is what should happen.  However, fb_set_var does a check
if the passed var is different from the default var.  If it's the same,
fb_set_par is skipped.  Switching back from X, this check will be mostly
false, so fb_set_par will be skipped, and register refreshing would have
failed.

So, I think fbcon should also detect if the previous console is not
fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if
it isn't, force an fb_set_par.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
> Actually it is normal. Changing a console via stty has been around 
> forever. When you ask what size is your VGA console you say 80x25. Now why 
> is that. The main thing is people think of it as a text mode and second
> you really can't change it or boot to to many different size resolutions.
> Does this mean VGA console should be limited? NO!!! I plan to make vgacon 
> some day changable in window size. So the final answer is:
> 
> Portablity. 
> 
> You could use stty or some other program using the tty layer to change the 
> resolution on any type of hardware running any type of console driver. The 
> next best thing is some day we can get ride of con_switch in the upper 
> console layers. We can just use set_font and vc_resize on VT switching 
> since that is all you are doing on vc_switching. 

OK, if this is your final word on this, I - as the maintainer of a 
driver which due to LCD and TV handling only supports a (huge) number of 
built-in modes - am forced to do the following:

If I receive a request for a mode that isn't supported, I go with the 
next larger one that is supported. Even if that leads to differences 
from requested 813x601 to displayed 1024x768.

Hope you and your console code can deal with that then :)

>>BTW: What happens currently if I instruct console to replace the current 
>>font with a bigger one (if that's possible at run-time at all) ?
> 
> 
> It should work.

... and lead to a mode switch? Funny: If I switch from a 8x16 font to a 
bigger one, because I forgot my glasses, the mode is switched to a 
higher one, because the number of cols and rows hasn't changed, leaving 
me with a nearly identical charcter size?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Sven Luther]

On Thu, Mar 06, 2003 at 09:33:34AM +0100, Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, James Simmons wrote:
> > > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > > Now if you think about it we can do things like change the bpp without 
> > > > having to redo the monitor programming. This is the flaw with the old and 
> > > > even the new api. 
> > > 
> > > You could have done that from the beginning. Just look at which fields have
> > > changed and which haven't.
> > 
> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One other reason why this isn't done is because X may interfere with it. If we
> don't do a full register update, but change the parts that need a change only,
> we will see less flickering (no PLL reprogramming), but we will suffer if X
> doesn't restore the registers to the exact same values they were before.

X is supposed to do that, even if it doesn't know anything about fbdevs,
maybe especially if it doesn't know anything about fbdevs. If it knows
about fbdev and uses it, X should not be touching the modes anyway,
right ?

So, we are saving/restoring things twice, one time in X, the other in
the fbdev.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
> fbcon_resize() is not that broken, it's only trying to do what it's
> supposed to do.  It is indeed limited because it is trying to outguess
> the low-level drivers on the best resolution for a window size.
> 
> However, the brokenness is really on the driver side.  They are unable
> to change the video mode unless they are supplied with the correct
> timing parameters where in fact they actually have the best knowledge on
> how to calculate them.  

Yes, BUT ONLY IF the driver has enough parameters to calculate it. This 
requires at least x and y dimension AND A CLOCK (or a vertical refresh 
rate, which I would prefer).

The driver is supposed to handle the "var"s it's fed. If that var is 
like the ones that result from the current fbcon_resize, namely with a 
new x and y res, but no valid clock, how on earth should the driver do 
this then? It receives a var which looks correct, and in fact, *could* 
be correct sometimes:

Suppose we have another application, say DirectFB, feeding the low level 
drivers with complete and correct "var"s.

In both cases we have valid x any y resultions, and a non-zero clock field.

Should we then let the driver read the x and y resolution and forget 
about the rest of that var? I hardly think that's what the public var is 
for. It could be reduced to a struct { USHORT xres, USHORT yres } then.

> So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
> we let the drivers calculate it for themselves?  I go for the latter, as
> fbcon really should not have any business with hardware.

What about the following solution: What if fbcon_resize sets the clock 
in the var to 0? We could use this to force low level drivers to decide 
on the clock for themselves. Otherwise, ie if the clock field is 
non-zero, they are supposed to take it as the desired clock.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, James Simmons wrote:
> > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > Now if you think about it we can do things like change the bpp without 
> > > having to redo the monitor programming. This is the flaw with the old and 
> > > even the new api. 
> > 
> > You could have done that from the beginning. Just look at which fields have
> > changed and which haven't.
> 
> I should of but didn't because I knew driver would take teh path of lest 
> resistance to port there drivers. TO much change would have made the 
> current situtation much much worst. 

One other reason why this isn't done is because X may interfere with it. If we
don't do a full register update, but change the parts that need a change only,
we will see less flickering (no PLL reprogramming), but we will suffer if X
doesn't restore the registers to the exact same values they were before.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 06:21, Thomas Winischhofer wrote:
> James Simmons wrote:
> > I disagree that fbset is the solution to all things. The problem is 
> > fbcon_resize is severally broken. The reality is that there are fixed mode 
> > resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> > shoudl do is set the console mode fit slightly smaller than that the 
> > actually resolution. The reason being is partially drawn fonts at the 
> > bottom of the screen would look bad. So clearing the margins also has to 
> > be fixed. This way we clean up the screen for situtations where the 
> > console screen size doesn't quite fit the resolution. This is what shoudl 
> > be done. 
> 
> Excuse me that I dare to comment on this as a total fbdev-rookie:
> 
> Please think about usability, too. Forcing people to fiddle with rows 
> and cols, requiring knowledge about font sizes and stuff is at least 
> inappropriate. Folks are used to think in resolutions, that's what they 
> understand, and that's what is most obvious. I can't imagine anyone 
> caring about the amount of rows or columns on a text screen.
> 

If you are working in a console, then you indeed need to work on rows
and columns.

> BTW: What happens currently if I instruct console to replace the current 
> font with a bigger one (if that's possible at run-time at all) ?

It will work, as the rows and columns are recalculated.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 03:43, James Simmons wrote:
> 
> > > I think you should only accept modes where the difference is a fraction
> > > of a character width or height.  A difference more than that and
> > > clear_margins() will not work correctly.  
> > > 
> > 
> > I apologize for my stupidity, fbdev does not know the font dimensions. 
> > I guess, we'll just need to really bring back fbset resizing.
> 
> I disagree that fbset is the solution to all things. The problem is 
> fbcon_resize is severally broken. The reality is that there are fixed mode 

fbcon_resize() is not that broken, it's only trying to do what it's
supposed to do.  It is indeed limited because it is trying to outguess
the low-level drivers on the best resolution for a window size.

However, the brokenness is really on the driver side.  They are unable
to change the video mode unless they are supplied with the correct
timing parameters where in fact they actually have the best knowledge on
how to calculate them.  

So the question:  Do we let fbcon spoonfeed the timings to fbdev, or do
we let the drivers calculate it for themselves?  I go for the latter, as
fbcon really should not have any business with hardware.

> resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> shoudl do is set the console mode fit slightly smaller than that the 
> actually resolution. The reason being is partially drawn fonts at the 

Yes, Geert's accel_clear_margin fix should help that.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 03:02, James Simmons wrote:
> > Yes, this is a limitation of stty.  It calls con_resize twice (one for
> > row and another for cols, depending on the order of the options) so it
> > will not work if the driver only supports a fixed set of modes.  Another
> > reason to bring back fbset resizing.
> 
> ???? stty rows 128 cols 48 works for me. It should'nt calling con_resize 
> twice. 
> 

It does.  You probably won't notice it if the driver supports flexible
video mode changing.  For drivers that don't it will fail.  For
instance, if a driver supports 800x600 and 1024x768 only, and stty is
used to change the mode from 1024x768 to 800x600, it will be done like
this:

resize to 800x768 <--- because no mode matches this, resizing fails
resize to 800x600

If you don't believe me, do an strace stty cols 80 rows 30.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Excuse me that I dare to comment on this as a total fbdev-rookie:

No problem. Its rare I take things personally. So I don't mind people 
critizing my work. You have to have a thick skin for this line of work.
 
> Please think about usability, too. Forcing people to fiddle with rows 
> and cols, requiring knowledge about font sizes and stuff is at least 
> inappropriate. Folks are used to think in resolutions, that's what they 
> understand, and that's what is most obvious. I can't imagine anyone 
> caring about the amount of rows or columns on a text screen.

Actually it is normal. Changing a console via stty has been around 
forever. When you ask what size is your VGA console you say 80x25. Now why 
is that. The main thing is people think of it as a text mode and second
you really can't change it or boot to to many different size resolutions.
Does this mean VGA console should be limited? NO!!! I plan to make vgacon 
some day changable in window size. So the final answer is:

Portablity. 

You could use stty or some other program using the tty layer to change the 
resolution on any type of hardware running any type of console driver. The 
next best thing is some day we can get ride of con_switch in the upper 
console layers. We can just use set_font and vc_resize on VT switching 
since that is all you are doing on vc_switching. 

P.S
   If you look at struct winsize you have a ws_xpixel and a ws_ypixel 
field. The question is now do we place the exact size of the screen in 
pixels or vc->font.width[height]*width[height]. So it is stty program 
that is limiting and not the tty layer. In theory you could write fbset to 
use the proper tty ioctl to do this.
 
> BTW: What happens currently if I instruct console to replace the current 
> font with a bigger one (if that's possible at run-time at all) ?

It should work.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > I should of but didn't because I knew driver would take teh path of lest 
> > resistance to port there drivers. TO much change would have made the 
> > current situtation much much worst. 
> 
> One could argue that changing stuff more or less constantly does not 
> make it any easier to keep up with a working driver.... :)

Well that was a policy change later on. At first the approach was small 
changes at a time. I was even converting each driver by myself. This upset 
some people. It was discussed the best solution would be to dump all the 
changes at one time and then let the driver maintainers deal with it. 
That is why the shift in what was going on.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
> I disagree that fbset is the solution to all things. The problem is 
> fbcon_resize is severally broken. The reality is that there are fixed mode 
> resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
> shoudl do is set the console mode fit slightly smaller than that the 
> actually resolution. The reason being is partially drawn fonts at the 
> bottom of the screen would look bad. So clearing the margins also has to 
> be fixed. This way we clean up the screen for situtations where the 
> console screen size doesn't quite fit the resolution. This is what shoudl 
> be done. 

Excuse me that I dare to comment on this as a total fbdev-rookie:

Please think about usability, too. Forcing people to fiddle with rows 
and cols, requiring knowledge about font sizes and stuff is at least 
inappropriate. Folks are used to think in resolutions, that's what they 
understand, and that's what is most obvious. I can't imagine anyone 
caring about the amount of rows or columns on a text screen.

BTW: What happens currently if I instruct console to replace the current 
font with a bigger one (if that's possible at run-time at all) ?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

James Simmons wrote:
>>>We should split the monitor programing stuff out from stuff like bpp etc.
>>>Now if you think about it we can do things like change the bpp without 
>>>having to redo the monitor programming. This is the flaw with the old and 
>>>even the new api. 
>>
>>You could have done that from the beginning. Just look at which fields have
>>changed and which haven't.
> 
> 
> I should of but didn't because I knew driver would take teh path of lest 
> resistance to port there drivers. TO much change would have made the 
> current situtation much much worst. 

One could argue that changing stuff more or less constantly does not 
make it any easier to keep up with a working driver.... :)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net          *** http://www.winischhofer.net



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > I think you should only accept modes where the difference is a fraction
> > of a character width or height.  A difference more than that and
> > clear_margins() will not work correctly.  
> > 
> 
> I apologize for my stupidity, fbdev does not know the font dimensions. 
> I guess, we'll just need to really bring back fbset resizing.

I disagree that fbset is the solution to all things. The problem is 
fbcon_resize is severally broken. The reality is that there are fixed mode 
resolutions (i.e. LCD displays). So fbcon has to adpat to this. What we 
shoudl do is set the console mode fit slightly smaller than that the 
actually resolution. The reason being is partially drawn fonts at the 
bottom of the screen would look bad. So clearing the margins also has to 
be fixed. This way we clean up the screen for situtations where the 
console screen size doesn't quite fit the resolution. This is what shoudl 
be done. 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Do you remember how modes were set before the existence of fbset? I guess not
> :-)

before my time.

> A driver could support up to 31 modes (cfr. the old minors). You changed mode
> by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
> the mode you wanted.

Yuck!!!!
 
> > userland database I often couldn't change video modes after booting. 
> 
> Ugh, those are serious driver bugs....

So the arrgument that fbset is the solution to all problems is bogus IMO.

> > We should split the monitor programing stuff out from stuff like bpp etc.
> > Now if you think about it we can do things like change the bpp without 
> > having to redo the monitor programming. This is the flaw with the old and 
> > even the new api. 
> 
> You could have done that from the beginning. Just look at which fields have
> changed and which haven't.

I should of but didn't because I knew driver would take teh path of lest 
resistance to port there drivers. TO much change would have made the 
current situtation much much worst. 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> Indeed, accel_clear_margins() calculates the margins as
> 
>     unsigned int cw = vc->vc_font.width;
>     unsigned int ch = vc->vc_font.height;
>     unsigned int rw = info->var.xres % cw;
>     unsigned int bh = info->var.yres % ch;
> 
> However, if it would use
> 
>     unsigned int rw = info->var.xres - (vc->vc_cols*cw);
>     unsigned int bh = info->var.yres - (vc->vc_rows*ch);
> 
> it would work with higher differences, too. And it would be a bit faster
> (multiply and subtract vs. modulo).

Applied.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, James Simmons wrote:
> On a personal note. Many fbdev drivers in 2.4.X where also broken in that 
> only the boot mode worked. This is where the fbset mode database in 
> userland hack came in (/etc/fb.modes). This is horriable. Even with that 

Do you remember how modes were set before the existence of fbset? I guess not
:-)

A driver could support up to 31 modes (cfr. the old minors). You changed mode
by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
the mode you wanted.

> userland database I often couldn't change video modes after booting. 

Ugh, those are serious driver bugs....

> We should split the monitor programing stuff out from stuff like bpp etc.
> Now if you think about it we can do things like change the bpp without 
> having to redo the monitor programming. This is the flaw with the old and 
> even the new api. 

You could have done that from the beginning. Just look at which fields have
changed and which haven't.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > I think that might be one reason for what I see :)
> 
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Note that there is still a bug in fbcon_resize().
> 
> 1.  in fbcon_resize(), p->vrows must be updated unconditionally

Applied in latest patch.
 
> 2.  fbcon_resize() in fbcon_switch() must be moved higher up the code,
> preferably before the scroll_phys_max calculation.

Do you have a patch?



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz
> 
> Note that this patch is dated Feb 20. In the mean time James applied at least
> your accel_putcs() optimizations and my logo updates.

Please note I just release a new patch. Please try it out.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > Well, this assumes that the user always want the best refresh rate, 
> > which is not desired in all cases.
> > 
> 
> fb_get_mode() accepts 4 flags.  Maximum refresh rate, hscan-driven,
> vrefresh-driven and dotclock-driven calculations.  It's flexible enough,
> but of course not as flexible as specifying your own modeline.

Things like pixclock rates can be changes by fbset and fbcon still 
sees these changes. stty is for the basic changes and fbset for advance 
changes. 

On a personal note. Many fbdev drivers in 2.4.X where also broken in that 
only the boot mode worked. This is where the fbset mode database in 
userland hack came in (/etc/fb.modes). This is horriable. Even with that 
userland database I often couldn't change video modes after booting. 

We should split the monitor programing stuff out from stuff like bpp etc.
Now if you think about it we can do things like change the bpp without 
having to redo the monitor programming. This is the flaw with the old and 
even the new api. 
 



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> > However, I could not manage to gain a graphical console if sisfb is a
> > module, but fbcon is in the kernel. Is this combination supposed to
> > work? If so, how?
> 
> No, fbcon will not load unless there's at least one registered fbdev.
> So, you must compile sisfb statically too.

I fixed this in my latest patch. You can use con2fb again!!!!!!

> > b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
> > but not the call to fbcon_resize() from within fbcon_switch(). This
> > leads to catastrophic drawing errors if the requested mode is not
> > supported by the low level driver.
> 
> Yes, it's a bug.  I think I submitted a patch to fix that, but I'm not
> sure if James applied it to his tree.

Applied.

> Another solution is to reimplement resizing by fbset.  The code is not
> very difficult and can be added if most people want it.

:-( 

> Yes, this is a limitation of stty.  It calls con_resize twice (one for
> row and another for cols, depending on the order of the options) so it
> will not work if the driver only supports a fixed set of modes.  Another
> reason to bring back fbset resizing.

???? stty rows 128 cols 48 works for me. It should'nt calling con_resize 
twice. 

> > 3) About y panning: In the 2.4 version of sisfb, I simply forced the
> > console to do y panning (unless positively disabled by the user) by
> > "patching" yres_virtual to the maximum, depending on the available video
> > memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
> > be believe so...)
> 
> Scrolling mode is now determined by fbcon.  If var->accel_flag is
> nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
> requres a lot of block copy which is slow when done by software.
> 
> I still believe though that scrolling should be determined by the
> driver, not fbcon.

Scrolling needs alot of work. I plan to fix that.



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[James Simmons]

> I am currently porting the SiS framebuffer driver to the - more or less
> - new API. Better late than never :)
> 
> Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
> development, no fbdev patches)

Please try your driver with the patch I post and tell me what problems you 
still have. Most of those shoudl have been fixes now.




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On 6 Mar 2003, Antonino Daplas wrote:
> On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote:
> > Antonino Daplas wrote:
> > >> > Strange.  If you boot at 800x600, the console will compute that as
> > >> > 100x37.  On fbcon_resize, it will request 800x592 but because the
> > >> > difference is only 8, fb_set_var should be skipped, so no mode change
> > >> > should happen throughout.
> > >>
> > >>But it definitely does. I can see this on my LCD (which goes dark during 
> > >>mode changes) and, of course, the log.
> > 
> > Just check this with the newest versions from fbdev at bk. In my code 
> > (which is, as I said in the beginning, the stock 2.5.63 kernel), 
> > fbcon_resize does NO check whatsoever. It stupidly calls set_var().
> 
> Of course.  My tree is so modified that I forgot that Jame's latest
> patch was not yet applied to the main tree :-)
> > 
> > I think that might be one reason for what I see :)
> 
> http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Note that this patch is dated Feb 20. In the mean time James applied at least
your accel_putcs() optimizations and my logo updates.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Thu, 2003-03-06 at 00:17, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> >> > Strange.  If you boot at 800x600, the console will compute that as
> >> > 100x37.  On fbcon_resize, it will request 800x592 but because the
> >> > difference is only 8, fb_set_var should be skipped, so no mode change
> >> > should happen throughout.
> >>
> >>But it definitely does. I can see this on my LCD (which goes dark during 
> >>mode changes) and, of course, the log.
> 
> Just check this with the newest versions from fbdev at bk. In my code 
> (which is, as I said in the beginning, the stock 2.5.63 kernel), 
> fbcon_resize does NO check whatsoever. It stupidly calls set_var().

Of course.  My tree is so modified that I forgot that Jame's latest
patch was not yet applied to the main tree :-)
> 
> I think that might be one reason for what I see :)

http://phoenix.infradead.org/~jsimmons/fbdev.diff.gz

Note that there is still a bug in fbcon_resize().

1.  in fbcon_resize(), p->vrows must be updated unconditionally

2.  fbcon_resize() in fbcon_switch() must be moved higher up the code,
preferably before the scroll_phys_max calculation.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:59, Thomas Winischhofer wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> > 
> >>Antonino Daplas wrote:
> >>
> >>>>Ack. Is 16 fuzzy enough, what do you think?
> >>>
> >>>I think you should only accept modes where the difference is a fraction
> >>>of a character width or height.  A difference more than that and
> >>>clear_margins() will not work correctly.  
> >>
> >>How do I - from a low level fb driver - determine the character size?
> > 
> > 
> > You cannot. That's called fbcon-fbdev separation.
> 
> My question was, basically, meant ironic.
> 
> But this is funny: You tell me that the difference should not exceed the 
> fraction of a character, but it is impossible to find out how wide/tall 
> characters are.
> 
> Guys, that won't work. I have to deal with LCD displays and TV output as 
> well (not to say "mainly") and I can't just set up odd modes like 
> 800x592, or mode resolutions based on calculations with any possible odd 
> font dimension.
> 

Yes, using stty is indeed limited.  This was implemented because midway
during development, when fbdev was completely separated from fbcon,
there was no way to resize the window at all.  The first solution was to
use stty, better it than none at all.  It did confuse a lot of people,
especially since not all drivers support changing the resolution without
help from the user.

Anyway, I have already brought fbset support back in my local copy :-)
As I've mentioned, I'll just wait for more replies to the "Feature
Freeze?" thread, and I'll submit a test patch.  

Tony

> Thomas
> 
> -- 
> Thomas Winischhofer
> Vienna/Austria
> mailto:thomas@winischhofer.net            http://www.winischhofer.net/
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>> > Strange.  If you boot at 800x600, the console will compute that as
>> > 100x37.  On fbcon_resize, it will request 800x592 but because the
>> > difference is only 8, fb_set_var should be skipped, so no mode change
>> > should happen throughout.
>>
>>But it definitely does. I can see this on my LCD (which goes dark during 
>>mode changes) and, of course, the log.

Just check this with the newest versions from fbdev at bk. In my code 
(which is, as I said in the beginning, the stock 2.5.63 kernel), 
fbcon_resize does NO check whatsoever. It stupidly calls set_var().

I think that might be one reason for what I see :)

Now for a plain dumb question: Is there a patch available to update my 
kernel tree to the latest fbdev stuff? (I don't intend to spend much 
time with bk)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> >>Antonino Daplas wrote:
> >>>>Ack. Is 16 fuzzy enough, what do you think?
> >>>
> >>>I think you should only accept modes where the difference is a fraction
> >>>of a character width or height.  A difference more than that and
> >>>clear_margins() will not work correctly.  
> >>
> >>How do I - from a low level fb driver - determine the character size?
> > 
> > 
> > You cannot. That's called fbcon-fbdev separation.
> 
> My question was, basically, meant ironic.
> 
> But this is funny: You tell me that the difference should not exceed the 
> fraction of a character, but it is impossible to find out how wide/tall 
> characters are.
> 
> Guys, that won't work. I have to deal with LCD displays and TV output as 
> well (not to say "mainly") and I can't just set up odd modes like 
> 800x592, or mode resolutions based on calculations with any possible odd 
> font dimension.

Indeed. That's why fbcon should adapt to fbdev, and not vice versa (IMHO).

I've always been a bit skeptical about the fbcon-driven fbdev-resizing...
I don't mind that you change the resolution or fontsize, but it should not
influence the fbdev too much.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:37, Thomas Winischhofer wrote:

> (shifted boot screen)
>  >>I am almost sure that this has to do with the fact that I adapt var in
>  >>my check_var from 800x592 to 800x600. Console (or whoever) seems to
>  >>attempt to change the mode to its initially desired dimension on many
>  >>occasions.
>  >
>  > Strange.  If you boot at 800x600, the console will compute that as
>  > 100x37.  On fbcon_resize, it will request 800x592 but because the
>  > difference is only 8, fb_set_var should be skipped, so no mode change
>  > should happen throughout.
> 
> But it definitely does. I can see this on my LCD (which goes dark during 
> mode changes) and, of course, the log.
> 
>  > I have no idea.  I booted with other drivers at 800x600 and get no ill
>  > effects.  I get a margin at the bottom of 8 pixels.
>  >
>  > How about checking what the offsets are during fb_pan_display()?
> 
> Done that. Nothing special; The penguin is where it should be, but the 
> text below starts 8 lines too low.
> 

How about removing fbcon_resize() from fbcon_switch()?  This should at
least give you an idea where the problem is (fbcon_resize, or somewhere
else)

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Geert Uytterhoeven wrote:
> On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> 
>>Antonino Daplas wrote:
>>
>>>>Ack. Is 16 fuzzy enough, what do you think?
>>>
>>>I think you should only accept modes where the difference is a fraction
>>>of a character width or height.  A difference more than that and
>>>clear_margins() will not work correctly.  
>>
>>How do I - from a low level fb driver - determine the character size?
> 
> 
> You cannot. That's called fbcon-fbdev separation.

My question was, basically, meant ironic.

But this is funny: You tell me that the difference should not exceed the 
fraction of a character, but it is impossible to find out how wide/tall 
characters are.

Guys, that won't work. I have to deal with LCD displays and TV output as 
well (not to say "mainly") and I can't just set up odd modes like 
800x592, or mode resolutions based on calculations with any possible odd 
font dimension.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:40, Geert Uytterhoeven wrote:
> On 5 Mar 2003, Antonino Daplas wrote:
> > On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:
> > > > Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> > > > it won't do an fb_set_var() if the change in dimensions is only a
> > > > fraction of a character's dimension.
> > > 
> > > Ack. Is 16 fuzzy enough, what do you think?
> > 
> > I think you should only accept modes where the difference is a fraction
> > of a character width or height.  A difference more than that and
> > clear_margins() will not work correctly.  
> 
> Indeed, accel_clear_margins() calculates the margins as
> 
>     unsigned int cw = vc->vc_font.width;
>     unsigned int ch = vc->vc_font.height;
>     unsigned int rw = info->var.xres % cw;
>     unsigned int bh = info->var.yres % ch;
> 
> However, if it would use
> 
>     unsigned int rw = info->var.xres - (vc->vc_cols*cw);
>     unsigned int bh = info->var.yres - (vc->vc_rows*ch);
> 
> it would work with higher differences, too. And it would be a bit faster
> (multiply and subtract vs. modulo).
> 

Yes, I believe so.  This way, it will make rounding off of values more
clear cut and still produce an acceptable display (albeit with possibly
wider margins).

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 23:25, Antonino Daplas wrote:

> > > 
> > > Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> > > it won't do an fb_set_var() if the change in dimensions is only a
> > > fraction of a character's dimension.
> > 
> > Ack. Is 16 fuzzy enough, what do you think?
> 
> I think you should only accept modes where the difference is a fraction
> of a character width or height.  A difference more than that and
> clear_margins() will not work correctly.  
> 

I apologize for my stupidity, fbdev does not know the font dimensions. 
I guess, we'll just need to really bring back fbset resizing.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On Wed, 5 Mar 2003, Thomas Winischhofer wrote:
> Antonino Daplas wrote:
> >>Ack. Is 16 fuzzy enough, what do you think?
> > I think you should only accept modes where the difference is a fraction
> > of a character width or height.  A difference more than that and
> > clear_margins() will not work correctly.  
> 
> How do I - from a low level fb driver - determine the character size?

You cannot. That's called fbcon-fbdev separation.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Geert Uytterhoeven]

On 5 Mar 2003, Antonino Daplas wrote:
> On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:
> > > Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> > > it won't do an fb_set_var() if the change in dimensions is only a
> > > fraction of a character's dimension.
> > 
> > Ack. Is 16 fuzzy enough, what do you think?
> 
> I think you should only accept modes where the difference is a fraction
> of a character width or height.  A difference more than that and
> clear_margins() will not work correctly.  

Indeed, accel_clear_margins() calculates the margins as

    unsigned int cw = vc->vc_font.width;
    unsigned int ch = vc->vc_font.height;
    unsigned int rw = info->var.xres % cw;
    unsigned int bh = info->var.yres % ch;

However, if it would use

    unsigned int rw = info->var.xres - (vc->vc_cols*cw);
    unsigned int bh = info->var.yres - (vc->vc_rows*ch);

it would work with higher differences, too. And it would be a bit faster
(multiply and subtract vs. modulo).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>>Ack. Is 16 fuzzy enough, what do you think?
> 
> 
> I think you should only accept modes where the difference is a fraction
> of a character width or height.  A difference more than that and
> clear_margins() will not work correctly.  

How do I - from a low level fb driver - determine the character size?

>>>I still believe though that scrolling should be determined by the
>>>driver, not fbcon.
>>
>>Well, what should I do now?
>>
>>The rivafb only forces y panning (ie sets yres_virtual to maximum) if 
>>yres_virtual is -1. This is never the case, as default var is constantly 
>>reused and I nowhere saw that any of the res_virtuals was set to -1.
>>
> 
> 
> For now, maximize yres_virtual, then set info->var.accel_flag to 1.

That's what I do.

(shifted boot screen)
 >>I am almost sure that this has to do with the fact that I adapt var in
 >>my check_var from 800x592 to 800x600. Console (or whoever) seems to
 >>attempt to change the mode to its initially desired dimension on many
 >>occasions.
 >
 > Strange.  If you boot at 800x600, the console will compute that as
 > 100x37.  On fbcon_resize, it will request 800x592 but because the
 > difference is only 8, fb_set_var should be skipped, so no mode change
 > should happen throughout.

But it definitely does. I can see this on my LCD (which goes dark during 
mode changes) and, of course, the log.

 > I have no idea.  I booted with other drivers at 800x600 and get no ill
 > effects.  I get a margin at the bottom of 8 pixels.
 >
 > How about checking what the offsets are during fb_pan_display()?

Done that. Nothing special; The penguin is where it should be, but the 
text below starts 8 lines too low.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 22:16, Thomas Winischhofer wrote:
> 
> Further to my mail from a few minutes ago:
> 
> I wrote:
>  > But I noticed another issue here:
>  >
>  > When switching to gfx mode during boot (ie as soon as the penguin
>  > appears), the text console is aligned correctly at all edges, with all
>  > lines visible.
> 
>  > But when "initial console" starts, the mode is again changed, and now
>  > the last line of text is nearly invisible, its upper half appears at
>  > the lower screen edge, the lower half is below the screen's edge. The
>  > space between the penguin and the text is notably thicker.
>  >
>  > This can be recovered by switching to another VT and back. This makes
>  > the penguin disappear, and restores the console dimensions/edges to
>  > normal.
> 
>  > Interestingly, this only happens with 800x600; this mode is chosen
>  > upon requesting 800x592 (because of the font size). At 1024x768,
>  > everything is as it should.
> 
> I am almost sure that this has to do with the fact that I adapt var in 
> my check_var from 800x592 to 800x600. Console (or whoever) seems to 
> attempt to change the mode to its initially desired dimension on many 
> occasions.
> 

Strange.  If you boot at 800x600, the console will compute that as
100x37.  On fbcon_resize, it will request 800x592 but because the
difference is only 8, fb_set_var should be skipped, so no mode change
should happen throughout.  

> - This leads to the (unncessary) second mode switch during boot (when 
> the "initial console" starts), assumingly because the xres does not 
> match fontsize * rows,

At boot time, there are several times the display changes (not
necessarily mode changes) --  while the logo is being displayed, after
the logo got displayed, and during init.

> 
> - and probably is the reason for that vertical offset I see after this 
> mode switch: The text area on the screen is shifted down by exactly 8 
> pixels - 600-592=8
> 
> Any hints?
> 

I have no idea.  I booted with other drivers at 800x600 and get no ill
effects.  I get a margin at the bottom of 8 pixels.

How about checking what the offsets are during fb_pan_display()?

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 22:06, Thomas Winischhofer wrote:

> >>However, I could not manage to gain a graphical console if sisfb is a
> >>module, but fbcon is in the kernel. Is this combination supposed to
> >>work? If so, how?
> > 
> > No, fbcon will not load unless there's at least one registered fbdev.
> > So, you must compile sisfb statically too.
> 
> Then this should definitely go into the kernel config rules, I guess :)
> 

I think so, except that fbcon will depend on so many drivers that no one
has the patience to add that to Kconfig yet :-)

> >>a) Calculating the desired mode resolution my simply multiplying the
> >>rows/cols by the font size very often results in odd modes like 800x592.
> >>This even when using a standard 8x16 font, not thinking of situations
> >>where for instance 12x22 fonts are used. How is the low level driver
> >>supposed to handle this?
> > 
> > Ideally, the driver should round up to the nearest mode it's capable
> > of.  The "fraction of a character dimensions" will be automatically
> > cleared by the "clear_margins" hook.
> 
> OK, that's exactly what I do now. I currently tend to the assumption 
> that this mode should be larger than the requested one...?

Yes. If it's smaller, it unconditionally calls fb_set_var(), I think.

> 
> >>To temporarily overcome this, I implemented a somewhat fuzzy mode
> >>identification routine, searching for modes with resolutions within a
> >>range of [desired res] - [desired res + 16]. But I can't imagine this
> >>being the Real Thing.
> > 
> > Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> > it won't do an fb_set_var() if the change in dimensions is only a
> > fraction of a character's dimension.
> 
> Ack. Is 16 fuzzy enough, what do you think?

I think you should only accept modes where the difference is a fraction
of a character width or height.  A difference more than that and
clear_margins() will not work correctly.  

> 
> > Right, using stty to change the window size assumes that the fbdev
> > driver has an algorithm to calculate modelines based on xres and yres
> > independently.  This is probably a bit of work for most driver authors.
> 
> Well, not as much work as more a lack of definition. If the user 
> specified a default of 800x600-75 I can't simply assume he also wants 
> 1024x768-75.
> 
> > There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that
> > should ease code writing if you have a VESA GTF compliant monitor.  You
> > can use that if you want as long as the display's operating limits are
> > known (info->monspecs).
> 
> Well, this assumes that the user always want the best refresh rate, 
> which is not desired in all cases.
> 

fb_get_mode() accepts 4 flags.  Maximum refresh rate, hscan-driven,
vrefresh-driven and dotclock-driven calculations.  It's flexible enough,
but of course not as flexible as specifying your own modeline.
  
> > Another solution is to reimplement resizing by fbset.  The code is not
> > very difficult and can be added if most people want it.
> 
> Awaiting public demand :)
> 

> > Yes, this is a limitation of stty.  It calls con_resize twice (one for
> > row and another for cols, depending on the order of the options) so it
> > will not work if the driver only supports a fixed set of modes.  Another
> > reason to bring back fbset resizing.
> 
> Think so, too. That's a really stupid behavior otherwise, since it 
> involves two mode changes, with one really undesired mode on the way.
> 
> > Scrolling mode is now determined by fbcon.  If var->accel_flag is
> > nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
> > requres a lot of block copy which is slow when done by software.
> > 
> > I still believe though that scrolling should be determined by the
> > driver, not fbcon.
> 
> Well, what should I do now?
> 
> The rivafb only forces y panning (ie sets yres_virtual to maximum) if 
> yres_virtual is -1. This is never the case, as default var is constantly 
> reused and I nowhere saw that any of the res_virtuals was set to -1.
> 

For now, maximize yres_virtual, then set info->var.accel_flag to 1.  It
wouldn't work until fbset support is reimplemented again, unless you
boot directly to that configuration.

I'll wait a few more days in hope of hearing from more people before
submitting a patch.

Tony




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Sorry, but I send mails faster than I can think sometimes:

 > - and probably is the reason for that vertical offset I see after this
 >  mode switch: The text area on the screen is shifted down by exactly 8
 > pixels - 600-592=8

Or perhaps the fbcon_resize stuff does

1) either not take the penguin into account,

or

2) does this too early, namely before the call to check_var()?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: Some questions

[Thomas Winischhofer]

Geert Uytterhoeven wrote:
>>Ideally, the driver should round up to the nearest mode it's capable
>>of.  The "fraction of a character dimensions" will be automatically
>>cleared by the "clear_margins" hook.
> 
> 
> But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, 
 > whatever the font may be.

Seems the fbdev people themselves aren't really happy with that stty 
solution...? :)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Thomas Winischhofer]

Further to my mail from a few minutes ago:

I wrote:
 > But I noticed another issue here:
 >
 > When switching to gfx mode during boot (ie as soon as the penguin
 > appears), the text console is aligned correctly at all edges, with all
 > lines visible.

 > But when "initial console" starts, the mode is again changed, and now
 > the last line of text is nearly invisible, its upper half appears at
 > the lower screen edge, the lower half is below the screen's edge. The
 > space between the penguin and the text is notably thicker.
 >
 > This can be recovered by switching to another VT and back. This makes
 > the penguin disappear, and restores the console dimensions/edges to
 > normal.

 > Interestingly, this only happens with 800x600; this mode is chosen
 > upon requesting 800x592 (because of the font size). At 1024x768,
 > everything is as it should.

I am almost sure that this has to do with the fact that I adapt var in 
my check_var from 800x592 to 800x600. Console (or whoever) seems to 
attempt to change the mode to its initially desired dimension on many 
occasions.

- This leads to the (unncessary) second mode switch during boot (when 
the "initial console" starts), assumingly because the xres does not 
match fontsize * rows,

- and probably is the reason for that vertical offset I see after this 
mode switch: The text area on the screen is shifted down by exactly 8 
pixels - 600-592=8

Any hints?

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Geert Uytterhoeven]

On 5 Mar 2003, Antonino Daplas wrote:
> > 3) The resizing using stty is - how do I put this - slightly imperfect.
> > I don't know how you fbdev folks do it, but I am not used to think in
> > row/col categories, but *resolutions* instead. Apart from this - IMHO a
> > bit annoying - inconvenience, this method has further issues:
> > 
> > a) Calculating the desired mode resolution my simply multiplying the
> > rows/cols by the font size very often results in odd modes like 800x592.
> > This even when using a standard 8x16 font, not thinking of situations
> > where for instance 12x22 fonts are used. How is the low level driver
> > supposed to handle this?
> 
> Ideally, the driver should round up to the nearest mode it's capable
> of.  The "fraction of a character dimensions" will be automatically
> cleared by the "clear_margins" hook.

But if I say e.g. `fbset 800x600-90', I do want a 90 Hz 800x600 mode, whatever
the font may be.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Thomas Winischhofer]

Antonino Daplas wrote:
>>Can anybody confirm that this (ie both low level driver and fbcon in
>>kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
>>implementation)? Did I perhaps miss anything, like a kernel parameter to
>>activate fbcon or similar?
> 
> Yes, it it does work.

OK, now it works here, too. Seems my debug-printks during initialisation 
made the kernel go bananas. As soon as I removed them, it walks along...

But I noticed another issue here:

When switching to gfx mode during boot (ie as soon as the penguin 
appears), the text console is aligned correctly at all edges, with all 
lines visible.

But when "initial console" starts, the mode is again changed, and now 
the last line of text is nearly invisible, its upper half appears at the 
lower screen edge, the lower half is below the screen's edge. The space 
between the penguin and the text is notably thicker.

This can be recovered by switching to another VT and back. This makes 
the penguin disappear, and restores the console dimensions/edges to normal.

Interestingly, this only happens with 800x600; this mode is chosen upon 
requesting 800x592 (because of the font size). At 1024x768, everything 
is as it should.

>>However, I could not manage to gain a graphical console if sisfb is a
>>module, but fbcon is in the kernel. Is this combination supposed to
>>work? If so, how?
> 
> No, fbcon will not load unless there's at least one registered fbdev.
> So, you must compile sisfb statically too.

Then this should definitely go into the kernel config rules, I guess :)

>>a) Calculating the desired mode resolution my simply multiplying the
>>rows/cols by the font size very often results in odd modes like 800x592.
>>This even when using a standard 8x16 font, not thinking of situations
>>where for instance 12x22 fonts are used. How is the low level driver
>>supposed to handle this?
> 
> Ideally, the driver should round up to the nearest mode it's capable
> of.  The "fraction of a character dimensions" will be automatically
> cleared by the "clear_margins" hook.

OK, that's exactly what I do now. I currently tend to the assumption 
that this mode should be larger than the requested one...?

>>To temporarily overcome this, I implemented a somewhat fuzzy mode
>>identification routine, searching for modes with resolutions within a
>>range of [desired res] - [desired res + 16]. But I can't imagine this
>>being the Real Thing.
> 
> Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
> it won't do an fb_set_var() if the change in dimensions is only a
> fraction of a character's dimension.

Ack. Is 16 fuzzy enough, what do you think?

> Right, using stty to change the window size assumes that the fbdev
> driver has an algorithm to calculate modelines based on xres and yres
> independently.  This is probably a bit of work for most driver authors.

Well, not as much work as more a lack of definition. If the user 
specified a default of 800x600-75 I can't simply assume he also wants 
1024x768-75.

> There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that
> should ease code writing if you have a VESA GTF compliant monitor.  You
> can use that if you want as long as the display's operating limits are
> known (info->monspecs).

Well, this assumes that the user always want the best refresh rate, 
which is not desired in all cases.

> Another solution is to reimplement resizing by fbset.  The code is not
> very difficult and can be added if most people want it.

Awaiting public demand :)

> Yes, this is a limitation of stty.  It calls con_resize twice (one for
> row and another for cols, depending on the order of the options) so it
> will not work if the driver only supports a fixed set of modes.  Another
> reason to bring back fbset resizing.

Think so, too. That's a really stupid behavior otherwise, since it 
involves two mode changes, with one really undesired mode on the way.

> Scrolling mode is now determined by fbcon.  If var->accel_flag is
> nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
> requres a lot of block copy which is slow when done by software.
> 
> I still believe though that scrolling should be determined by the
> driver, not fbcon.

Well, what should I do now?

The rivafb only forces y panning (ie sets yres_virtual to maximum) if 
yres_virtual is -1. This is never the case, as default var is constantly 
reused and I nowhere saw that any of the res_virtuals was set to -1.

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Antonino Daplas]

On Wed, 2003-03-05 at 20:18, Thomas Winischhofer wrote:
> I am currently porting the SiS framebuffer driver to the - more or less
> - new API. Better late than never :)
> 
> Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
> development, no fbdev patches)
> 
> 1) Sisfb currently does not work if compiled statically into the kernel.
> (It works as a module if fbcon is a module, too). If sisfb and fbcon are
> the kernel, the mode switch occures but the only thing I see is a white
> rectangle at the left egde of the screen, vertically centered, with some
> flashing grey dots. I almost looks like text mode output while in
> graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
> Finally, it seems to oops, but I can't say that for sure because I don't
> see anything (and I unfortunately don't have a serial console available).
> 
> Can anybody confirm that this (ie both low level driver and fbcon in
> kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
> implementation)? Did I perhaps miss anything, like a kernel parameter to
> activate fbcon or similar?

Yes, it it does work.

> 
> 2) If both sisfb and fbcon are modules, everything works s supposed when
> first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
> switch occures and I see a graphical console (with a white rectangle of
> the size of the previous console size which vanishes upon pressing enter).

Ideally, fbdev should only change the video mode on the first fb_open()
or fb_set_par() and restore the state on the last fb_close().  This is
so you can load fbdev without having a framebuffer console.  If memory
serves me correctly, that's how sisfb in 2.4 works?.

> 
> However, I could not manage to gain a graphical console if sisfb is a
> module, but fbcon is in the kernel. Is this combination supposed to
> work? If so, how?

No, fbcon will not load unless there's at least one registered fbdev.
So, you must compile sisfb statically too.

> 
> 3) The resizing using stty is - how do I put this - slightly imperfect.
> I don't know how you fbdev folks do it, but I am not used to think in
> row/col categories, but *resolutions* instead. Apart from this - IMHO a
> bit annoying - inconvenience, this method has further issues:
> 
> a) Calculating the desired mode resolution my simply multiplying the
> rows/cols by the font size very often results in odd modes like 800x592.
> This even when using a standard 8x16 font, not thinking of situations
> where for instance 12x22 fonts are used. How is the low level driver
> supposed to handle this?

Ideally, the driver should round up to the nearest mode it's capable
of.  The "fraction of a character dimensions" will be automatically
cleared by the "clear_margins" hook.

> 
> To temporarily overcome this, I implemented a somewhat fuzzy mode
> identification routine, searching for modes with resolutions within a
> range of [desired res] - [desired res + 16]. But I can't imagine this
> being the Real Thing.

Yes, that's the Real Thing :-)  fbcon_resize has a "fuzzy mode" too --
it won't do an fb_set_var() if the change in dimensions is only a
fraction of a character's dimension.

> 
> b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
> but not the call to fbcon_resize() from within fbcon_switch(). This
> leads to catastrophic drawing errors if the requested mode is not
> supported by the low level driver.

Yes, it's a bug.  I think I submitted a patch to fix that, but I'm not
sure if James applied it to his tree.

> 
> c) fbcon_resize() only changes var.xres and var.yres, leaving everything
> else - var.pixclock, for instance - alone. fb_set_var() just calles the
> driver's check_var() routine and then set_par(). How is the low level
> driver supposed to behave in this situation, especially considering the
> unchanged pixclock?
> 

Right, using stty to change the window size assumes that the fbdev
driver has an algorithm to calculate modelines based on xres and yres
independently.  This is probably a bit of work for most driver authors. 
There's new code in fbmon.c (fb_find_mode and fb_validate_mode) that
should ease code writing if you have a VESA GTF compliant monitor.  You
can use that if you want as long as the display's operating limits are
known (info->monspecs).

Another solution is to reimplement resizing by fbset.  The code is not
very difficult and can be added if most people want it.

> d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
> works after all (see a)), but only if I execute stty twice. The desired
> mode the low level driver receives at the first attempt is 800x768.
> Could this be related to an outdated or buggy stty, calling the console
> code twice if rows and cols are specified at the same time...?

Yes, this is a limitation of stty.  It calls con_resize twice (one for
row and another for cols, depending on the order of the options) so it
will not work if the driver only supports a fixed set of modes.  Another
reason to bring back fbset resizing.

> 
> 3) About y panning: In the 2.4 version of sisfb, I simply forced the
> console to do y panning (unless positively disabled by the user) by
> "patching" yres_virtual to the maximum, depending on the available video
> memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
> be believe so...)

Scrolling mode is now determined by fbcon.  If var->accel_flag is
nonzero, scrolling is ypan, otherwise, it's yredraw.  It's because ypan
requres a lot of block copy which is slow when done by software.

I still believe though that scrolling should be determined by the
driver, not fbcon.

Tony 




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Some questions

[Thomas Winischhofer]

I am currently porting the SiS framebuffer driver to the - more or less
- new API. Better late than never :)

Anyway, during this, I noticed some issues: (I am using stock 2.5.63 for
development, no fbdev patches)

1) Sisfb currently does not work if compiled statically into the kernel.
(It works as a module if fbcon is a module, too). If sisfb and fbcon are
the kernel, the mode switch occures but the only thing I see is a white
rectangle at the left egde of the screen, vertically centered, with some
flashing grey dots. I almost looks like text mode output while in
graphics mode, or - better - if fbcon assumes a font size of 1 pixel.
Finally, it seems to oops, but I can't say that for sure because I don't
see anything (and I unfortunately don't have a serial console available).

Can anybody confirm that this (ie both low level driver and fbcon in
kernel) is supposed to work in 2.5.63 (making it a bug in my sisfb
implementation)? Did I perhaps miss anything, like a kernel parameter to
activate fbcon or similar?

2) If both sisfb and fbcon are modules, everything works s supposed when
first modprobing sisfb and then fbcon. Upon modprobing fbcon, the mode
switch occures and I see a graphical console (with a white rectangle of
the size of the previous console size which vanishes upon pressing enter).

However, I could not manage to gain a graphical console if sisfb is a
module, but fbcon is in the kernel. Is this combination supposed to
work? If so, how?

3) The resizing using stty is - how do I put this - slightly imperfect.
I don't know how you fbdev folks do it, but I am not used to think in
row/col categories, but *resolutions* instead. Apart from this - IMHO a
bit annoying - inconvenience, this method has further issues:

a) Calculating the desired mode resolution my simply multiplying the
rows/cols by the font size very often results in odd modes like 800x592.
This even when using a standard 8x16 font, not thinking of situations
where for instance 12x22 fonts are used. How is the low level driver
supposed to handle this?

To temporarily overcome this, I implemented a somewhat fuzzy mode
identification routine, searching for modes with resolutions within a
range of [desired res] - [desired res + 16]. But I can't imagine this
being the Real Thing.

b) The call to fb_set_var() inside fbcon_resize() is checked for errors,
but not the call to fbcon_resize() from within fbcon_switch(). This
leads to catastrophic drawing errors if the requested mode is not
supported by the low level driver.

c) fbcon_resize() only changes var.xres and var.yres, leaving everything
else - var.pixclock, for instance - alone. fb_set_var() just calles the
driver's check_var() routine and then set_par(). How is the low level
driver supposed to behave in this situation, especially considering the
unchanged pixclock?

d) Starting with a mode of 1024x768 and resizing to 800x600 using stty
works after all (see a)), but only if I execute stty twice. The desired
mode the low level driver receives at the first attempt is 800x768.
Could this be related to an outdated or buggy stty, calling the console
code twice if rows and cols are specified at the same time...?

3) About y panning: In the 2.4 version of sisfb, I simply forced the
console to do y panning (unless positively disabled by the user) by
"patching" yres_virtual to the maximum, depending on the available video
memory. I am allowed to do that with the 2.5 API? (The rivafb code makes
be believe so...)

Thomas

-- 
Thomas Winischhofer
Vienna/Austria
mailto:thomas@winischhofer.net            http://www.winischhofer.net/





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Some questions

[Paul Krumviede]

trimmed to ssh only...

--On Friday, 05 October, 2001 09:57 -0400 Stephen Smalley <sds@tislabs.com> 
wrote:

>
> On 5 Oct 2001, Justin R. Smith wrote:
>
>> 3. SSH no longer recognizes my authorized keys --- I must always enter a
>> password to use it. I've regenerated the keys several times (putting the
>> appropriate public keys in 'authorized_keys') without success. I know
>> the sshd on my system was replaced by another. Does it function
>> differently?
>
> The utils Makefile only installs the modified sshd, not the rest of the
> package, since we only modified sshd.  So if you were using a different
> version of OpenSSH, you might have a compatibility problem.  The openssh
> package provided with SELinux is the default one provided with RedHat 7.1
> with the SELinux modifications.  If you are using a newer version of
> OpenSSH, then I would suggest porting the SELinux patch forward to the
> newer version (and please feed the resulting patch back to us).  If you
> are using an older version of OpenSSH, then I would suggest doing a 'make
> install' in the openssh-2.5.2p2-5 directory and then doing a 'make
> relabel' in the utils directory.

i've had to force use of the version 2 protocol to make this work, either
via the command line option to ssh or by changing the sshd_config file
to only use protocol version 2. doing what is suggested above was not
sufficient for me - i was trying to make this work separately some time
ago (and i think i've had to do this on a base redhat 7.0 system, if i
recall the circumstances correctly). i don't know if it matters or not,
but this was when i had a DSA key present; i haven't tried it with
only RSA keys.

-paul


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Some questions

[Stephen Smalley]

On 5 Oct 2001, Justin R. Smith wrote:

> I've installed the latest version of SELinux in permissive mode.
>
> 1. I've noticed no unusual messages in dmesg or /var/log/messages. Does
> this mean that my normal activities do not violate any of the new access
> restrictions? (So enabling secure mode would not disrupt any of the
> things I normally do)?

Possibly.  Please check the 'ps -e --context' output and verify that each
system process is running in the correct security context.  Also, please
verify that your security context is set properly when you login (run
'id' or 'ps --context').  And make sure that you aren't running a X
Display Manager, as I mentioned in my prior email to James Bishop.

> 2. If I toggle fully secure mode, can I reverse this remotely (i.e., ssh
> to the host, su, and execute the toggle command again)?

You don't need to 'su' - you need to run 'newrole -r sysadm_r'.  SELinux
doesn't care whether you are root.  It cares about your role and domain.
Yes, this should work remotely (unless you change the policy to prohibit
it).  You can test it while still in permissive mode - simply try it and
check /var/log/messages and the output of dmesg for any messages.

> 3. SSH no longer recognizes my authorized keys --- I must always enter a
> password to use it. I've regenerated the keys several times (putting the
> appropriate public keys in 'authorized_keys') without success. I know
> the sshd on my system was replaced by another. Does it function
> differently?

The utils Makefile only installs the modified sshd, not the rest of the
package, since we only modified sshd.  So if you were using a different
version of OpenSSH, you might have a compatibility problem.  The openssh
package provided with SELinux is the default one provided with RedHat 7.1
with the SELinux modifications.  If you are using a newer version of
OpenSSH, then I would suggest porting the SELinux patch forward to the
newer version (and please feed the resulting patch back to us).  If you are
using an older version of OpenSSH, then I would suggest doing a 'make
install' in the openssh-2.5.2p2-5 directory and then doing a 'make
relabel' in the utils directory.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Some questions

[Justin R. Smith]

I've installed the latest version of SELinux in permissive mode.

1. I've noticed no unusual messages in dmesg or /var/log/messages. Does
this mean that my normal activities do not violate any of the new access
restrictions? (So enabling secure mode would not disrupt any of the
things I normally do)?

2. If I toggle fully secure mode, can I reverse this remotely (i.e., ssh
to the host, su, and execute the toggle command again)?

3. SSH no longer recognizes my authorized keys --- I must always enter a
password to use it. I've regenerated the keys several times (putting the
appropriate public keys in 'authorized_keys') without success. I know
the sshd on my system was replaced by another. Does it function
differently? 

Here's a log from the debug mode for ssh (on my home computer, I use the
latest version of ssh and a DSA key):

debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug3: start over, passed a different list
publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug2: userauth_pubkey_agent: no keys at all
debug2: userauth_pubkey_agent: no more keys
debug2: userauth_pubkey_agent: no message sent
debug1: try privkey: /home/jsmith/.ssh/identity
debug3: no such identity: /home/jsmith/.ssh/identity
debug1: try privkey: /home/jsmith/.ssh/id_rsa
debug3: no such identity: /home/jsmith/.ssh/id_rsa
debug1: try pubkey: /home/jsmith/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug2: userauth_pubkey_agent: no more keys

-- 



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Some questions...

[Steve Rikli]

ralf@uni-koblenz.de wrote:
> On Sat, Jun 06, 1998 at 08:32:49AM +0200, Peter Maydell wrote:
> 
> > Ariel Faigon wrote:
> > >	1) If you have the Indy (hardware) you already have
> > >	   the license for IRIX (for your own use)
> > 
> > Does this hold for earlier machines as well? I have a 4D/70GT with no
> > system software... 
> > 
> > While I'm here, I thought I'd look into the feasibility of porting
> > Linux to this machine. [In fact, I'm probably not going to have access
> > to the machine for long enough to work on it, but maybe somebody else
> > will. (the machine belongs to the Computer Preservation Society here in
> > Cambridge...)]
> > 
> > Anyway, points that spring to mind:
> > * the CPU is an R2000; I don't think any of the current ports are for
> > less than an R3000 -- does anybody know how different the R2000 is?
> 
> The R3000 is basically an R2000 which has undergone an overhaul to make
> higher clockrate possible.  With respect to software R2000 and R3000 are
> 100% compatible with the exception that the product ID register c0_prid
> contains a different value.
> 
> For those of you who are not reading linux-mips@fnet.fr, Harald yesterday
> managed to bring his DECstation into userland booting from a ramdisk, so a
> large fraction of the job has been done.
> 
> > * without hardware documentation I suspect it will be impossible to get
> > anywhere. Every board seems to have a CPU on it :-> The ESDI and ethernet
> > boards both have 68000s, and the graphics board set has a 68020 complete
> > with debugging monitor you can access via a serial terminal, in addition
> > to all those custom chips...
> > Are SGI being helpful about providing documentation on the older hardware?
> 
> This is one point.  The other is as somebody else mentioned in this thread
> that few people actually still have such a machine, the number of active
> kernel hackers will be even lower.  Given that and that the machine is
> unsupported since a long time, maybe SGI might even consider contributing
> sources for such ancient systems as long as they're not poisoned with AT&T
> (C) stuff ...

This might be an opportune time to point out the "This Old SGI" website
again:

	http://www.geocities.com/SiliconValley/Pines/2258/4dfaq.html

I dunno how helpful the info therein will be wrt Linux porting, but from
a purely selfish point of view I'd love to see Linux running on the 4D
(especially MP boxes like 4D/440 et al) series & other R3K boxes (e.g.
classic Indigo) since I personally own a couple of them.  ;)

cheers,
sr.
-- 
|| Steve Rikli <sr@sgi.com> |||                                         ||
|| Systems Administrator    ||| How can something that is almost 3 MB   ||
|| SNS, EIS Infrastructure  ||| in size be called a "kernel"?           ||
|| Silicon Graphics, Inc.   |||                                         ||

Re: Some questions...

[ralf]

On Sat, Jun 06, 1998 at 08:32:49AM +0200, Peter Maydell wrote:

> Ariel Faigon wrote:
> >	1) If you have the Indy (hardware) you already have
> >	   the license for IRIX (for your own use)
> 
> Does this hold for earlier machines as well? I have a 4D/70GT with no
> system software... 
> 
> While I'm here, I thought I'd look into the feasibility of porting
> Linux to this machine. [In fact, I'm probably not going to have access
> to the machine for long enough to work on it, but maybe somebody else
> will. (the machine belongs to the Computer Preservation Society here in
> Cambridge...)]
> 
> Anyway, points that spring to mind:
> * the CPU is an R2000; I don't think any of the current ports are for
> less than an R3000 -- does anybody know how different the R2000 is?

The R3000 is basically an R2000 which has undergone an overhaul to make
higher clockrate possible.  With respect to software R2000 and R3000 are
100% compatible with the exception that the product ID register c0_prid
contains a different value.

For those of you who are not reading linux-mips@fnet.fr, Harald yesterday
managed to bring his DECstation into userland booting from a ramdisk, so a
large fraction of the job has been done.

> * without hardware documentation I suspect it will be impossible to get
> anywhere. Every board seems to have a CPU on it :-> The ESDI and ethernet
> boards both have 68000s, and the graphics board set has a 68020 complete
> with debugging monitor you can access via a serial terminal, in addition
> to all those custom chips...
> Are SGI being helpful about providing documentation on the older hardware?

This is one point.  The other is as somebody else mentioned in this thread
that few people actually still have such a machine, the number of active
kernel hackers will be even lower.  Given that and that the machine is
unsupported since a long time, maybe SGI might even consider contributing
sources for such ancient systems as long as they're not poisoned with AT&T
(C) stuff ...

  Ralf

Re: Some questions...

[Jeremy John Welling]

Um, on top of the reasons you've already sited, I don't think there's
enough of those behemoth's still in operational existence to make a port
worth while.  I'm no hardware expert, but other than the original os,
there's not much you can do for that old box.  

On Sat, 6 Jun 1998, Peter Maydell wrote:

> Ariel Faigon wrote:
> >	1) If you have the Indy (hardware) you already have
> >	   the license for IRIX (for your own use)
> 
> Does this hold for earlier machines as well? I have a 4D/70GT with no
> system software... 
> 
> While I'm here, I thought I'd look into the feasibility of porting
> Linux to this machine. [In fact, I'm probably not going to have access
> to the machine for long enough to work on it, but maybe somebody else
> will. (the machine belongs to the Computer Preservation Society here in
> Cambridge...)]
> 
> Anyway, points that spring to mind:
> * the CPU is an R2000; I don't think any of the current ports are for
> less than an R3000 -- does anybody know how different the R2000 is?
> 
> * without hardware documentation I suspect it will be impossible to get
> anywhere. Every board seems to have a CPU on it :-> The ESDI and ethernet
> boards both have 68000s, and the graphics board set has a 68020 complete
> with debugging monitor you can access via a serial terminal, in addition
> to all those custom chips...
> Are SGI being helpful about providing documentation on the older hardware?
> 
> Peter Maydell
> 

Re: Some questions...

[Peter Maydell]

Ariel Faigon wrote:
>	1) If you have the Indy (hardware) you already have
>	   the license for IRIX (for your own use)

Does this hold for earlier machines as well? I have a 4D/70GT with no
system software... 

While I'm here, I thought I'd look into the feasibility of porting
Linux to this machine. [In fact, I'm probably not going to have access
to the machine for long enough to work on it, but maybe somebody else
will. (the machine belongs to the Computer Preservation Society here in
Cambridge...)]

Anyway, points that spring to mind:
* the CPU is an R2000; I don't think any of the current ports are for
less than an R3000 -- does anybody know how different the R2000 is?

* without hardware documentation I suspect it will be impossible to get
anywhere. Every board seems to have a CPU on it :-> The ESDI and ethernet
boards both have 68000s, and the graphics board set has a 68020 complete
with debugging monitor you can access via a serial terminal, in addition
to all those custom chips...
Are SGI being helpful about providing documentation on the older hardware?

Peter Maydell

Re: Some questions...

[Ariel Faigon]

:
:
:What are the implications of us redistributing the header files from Irix?
:In particular, there are some header files for newport graphics that are
:needed.
:

My personal reasoning for "it is not really a problem"
stems from the following facts:

	1) If you have the Indy (hardware) you already have
	   the license for IRIX (for your own use)

	2) Unlike in earlier days where you had so buy a "developer's CD"
	   to get headers"   SGI is now including header files standard
	   with the system (since 6.2 at least).

	3) Newport graphics is ancient technology (about 6 years old)

Having said that, all these headers usually have this on top:
/**************************************************************************
 *                                                                        *
 *               Copyright (C) 1996 Silicon Graphics, Inc.                *
 *                                                                        *
 *  These coded instructions, statements, and computer programs  contain  *
 *  unpublished  proprietary  information of Silicon Graphics, Inc., and  *
 *  are protected by Federal copyright law.  They  may  not be disclosed  *
 *  to  third  parties  or copied or duplicated in any form, in whole or  *
 *  in part, without the prior written consent of Silicon Graphics, Inc.  *
 *                                                                        *
 **************************************************************************/

So clearly we should get permission from the "powers that be" and
someone needs to ask the legal people :-)   I just don't know
what entity can approve this.  If anyone knows and we can get
a brief "approved" from some director, it would be nice.

Any volunteers ?

-- 
Peace, Ariel

Re: Some questions...

[Ariel Faigon]

:
:
:What are the implications of us redistributing the header files from Irix?
:In particular, there are some header files for newport graphics that are
:needed.
:

My personal reasoning for "it is not really a problem"
stems from the following facts:

	1) If you have the Indy (hardware) you already have
	   the license for IRIX (for your own use)

	2) Unlike in earlier days where you had so buy a "developer's CD"
	   to get headers"   SGI is now including header files standard
	   with the system (since 6.2 at least).

	3) Newport graphics is ancient technology (about 6 years old)

Having said that, all these headers usually have this on top:
/**************************************************************************
 *                                                                        *
 *               Copyright (C) 1996 Silicon Graphics, Inc.                *
 *                                                                        *
 *  These coded instructions, statements, and computer programs  contain  *
 *  unpublished  proprietary  information of Silicon Graphics, Inc., and  *
 *  are protected by Federal copyright law.  They  may  not be disclosed  *
 *  to  third  parties  or copied or duplicated in any form, in whole or  *
 *  in part, without the prior written consent of Silicon Graphics, Inc.  *
 *                                                                        *
 **************************************************************************/

So clearly we should get permission from the "powers that be" and
someone needs to ask the legal people :-)   I just don't know
what entity can approve this.  If anyone knows and we can get
a brief "approved" from some director, it would be nice.

Any volunteers ?

-- 
Peace, Ariel

Some questions...

[Alex deVries]

What are the implications of us redistributing the header files from Irix?
In particular, there are some header files for newport graphics that are
needed.

Oliver, how's the fdisk port going?

- Alex



-- 
Alex deVries, puffin on LinuxNet.
http://www.engsoc.carleton.ca/~adevries/ .