# Copyright 2006 Vito Caputo - <vcaputo@pengaru.com>
#

# The parsing format is defined by libconfuse, a LGPL'd configuration parser:
# http://sv.nongnu.org/projects/confuse

#Eventually, this should just be generated by the program, but for now manual
#editing will have to do.


# First we enumerate connected devices, the id we assign is used to refer to
# the device later when we define objects that use data it provides.


# The label given after the device keyword identifies which module this device
# uses, basically it tells the program what code to talk to the device with.
# Based on what module you are using, the configuration options available for
# that device vary, but at the moment they are relatively uniform.
#
# There is one member which will always be available, and that is "id", which we
# explained briefly above.  The id is usually combined with additional
# identifiers seperated by a "." when used in a reference, like "e6k.tps" for
# the tps (throttle position sensor) object in the e6k device, which is only
# called "e6k" because id was set to it, it could have been nearly anything,
# i.e. "foo.tps", if id were "foo".
# The only limitation on device id setting is your id string cannot contain a
# "." because this is reserved for obvious reasons (used as delimiter).
#
# Note you do not get to define the sub-id for the data source members,
# like tps, rpm, etc... these are defined by the module as it knows what
# kind of data it can provide, lists of possible sub-ids per-module will
# be available.

# haltech module: (Haltech Inc. Australian standalone engine management co.)
#	device:	path to the device connected to the haltech ecu
#	model:	a string identifying which e6 model it is,
#		currently only "e6k" and "e6x" supported.

# techedge module: (TechEdge Inc. maker of the diy-wbo2 wideband-o2 controllers)
#	device: path to the device connected to the techedge controller
#	model:	a string identifying which controller model it is,
#		currently only "2a0" is supported.

# picotech module: (PicoTech parallel ADC interface)
#	device: path to the device connected to the PicoTech device
#	model:	a string identifying which device model it is,
#		currently only "adc11" is supported.



# you must define any device before other parts of the configuration can
# refer to an object member of such device.
#
# also note that by including a source here, the program will try
# to communicate with the source and make data from that source
# available.  If you are not using the source comment it out, it will make the
# program more efficient.
device haltech {
	id = "e6k"
	device = "/dev/ttyS0"
	model = "e6k"
}

device techedge {
	id = "te"
	device = "/dev/ttyS1"
	model = "2a0"
}

#hint hint
#source obd {
#	type = "obd2"
#	device = "/dev/ttyS3"
#}




# Now include some fonts for rendering text.
# The label given after font is used to refer to the font later.
# If the font file doesnt exist / isnt found / cant be read, it has
# the same effect as the font clause not existing in this file.
font italics {
	file = "italics.ttf"
	#may add some more options later...
}

font sans {
	file = "sans.ttf"
}




# now for some global things, like screen resolution
resolution = "800x600"
wait_for_vertical_retrace = true

#some alarms

# a shift light
alarm shift_light {
	source = "e6k.rpm"
	on_value = 10000
	off_value = 9500
	action = "screen_flash"
	color = 10
}

# a overheating flash
alarm hot {
	source = "e6k.clt"
	on_value = 230
	off_value = 210
	action = "screen_flash"
	color = 11
}



pager root {
	width = 800
	height = 600
	x = 0
	y = 0

	# page entries, these page entries control the visual layout of the program,
	# there can be many page entries, they are cycled through the program by hitting
	# tab / shift tab.

	# the drawing order of the objects within a page is determined by the order the
	# objects appear here within the page clause, so with the example below, the rpm
	# gauge gets drawn first, then tps, wbo2...  often this will be totally
	# unimportant.  But when you start making more intricate layouts with
	# overlapping gauge areas, it becomes significant.
	#
	#
	# This is because when you have overlapping areas there is sometimes one that
	# has contents which need to be visible within the overlapping region, this is
	# the one that must be drawn last out of the affected objects intersecting in
	# the region of overlap.  This usually happens when you have a circular gauge
	# that is being used in a half-moon fashion, and you want to let another gauge
	# drawn its significant contents into the unused portion of the circle for the
	# half-moon gauge.  To do this, you must make the gauge that is consuming the
	# empty area of the half-moon circle draw after the half-moon gauge, if you let
	# the half-moon render after, it will obscure the other gauge with background
	# contents, either a solid color or the backdrop if one is configured.  There is
	# no harm in having gauges overlap, it just makes creating the layout slightly
	# more complex.
	#
	# note that this does not affect any visible order of drawing or latency on any 
	# particular gauges, this controls the order of drawing when the program is
	# rendering the page into a buffer that is not visible.  When the page is fully
	# rendered off-screen it is then made visible atomically / at once.  So the
	# drawing order basically just controls the order things are being stacked up on
	# the display.  There is no advantage to any particular object getting to be
	# first in the drawing order.


	page driving {
		backdrop = "driving_backdrop.png"

		gauge RPM {
			source = "e6k.rpm"
			style = 1

	# these values are coordinates within the page, page upper left is 0,0 the units
	# are pixels
			x = 100
			y = 100
			width = 100
			height = 100

	# these values are coordinates within the gauge, gauge upper left is 0,0 the
	# units are pixels
			value_x = 20
			value_y = 30


	#these control the appearance of the gauge
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true

			indicator_size = 100



	# These control the drawn scales, if you don't define a scale none will be
	# displayed unless you include scales in your backdrop image, which works fine
	# and lets you get some unique styles but has the inconvenience of requiring
	# you to align the scale_start and scale_end with the scales you've drawn
	# in the backdrop... if you use the generated scales they are rendered using
	# the scale_start and scale_end values, making the indicator position and
	# scales automatically agree.

			scale hundreds {
				hatch_size = 10
				delta = 100
				show_value = false
			}

			scale thousands {
				hatch_size = 30
				delta = 1000
				show_value = true
				value_multiplier = .001
			}
		}



		gauge TPS {
			source = "e6k.tps"
			style = 1
			x = 200
			y = 200
			width = 20
			height = 20
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true
		}

		gauge WBo2 {
			source = "te.wbo2"
			style = 2
			x = 10
			y = 500
			width = 20
			height = 20
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true
		}

		gauge Water {
			source = "e6k.clt"
			style = 1
			x = 200
			y = 200
			width = 20
			height = 20
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true
		}

		gauge Air {
			source = "e6k.ait"
			style = 1
			x = 200
			y = 200
			width = 20
			height = 20
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true
		}

		gauge Fuel {
			source = "e6k.adc"
			style = 1
			x = 200
			y = 200
			width = 20
			height = 20
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true
		}

		gauge Speed {
			source = "e6k.rss"
			style = 1
			x = 200
			y = 200
			width = 20
			height = 20
			font = italics
			font_size = 12
			scale_start = 0
			scale_end = 320
			show_name = false
			show_value = true
		}
	}



	#page diagnostics {
	# TODO, just a pile of horizontal gauges, a layout like this one is nice when
	# it's autogenerated due to the uniformity :/
	#}


	# this page does something interesting, it includes a pager for the map editing,
	# where all the maps get enumerated
	#page tuning {
	#	pager maps {
	#		width = 800
	#		height = 400
	#
	#		map Fuel {
	#			style = 2
	#			source = "e6k.maps.fuel"
	#		}
	#
	#		map Ignition {
	#			style = 2
	#			source = "e6k.maps.ignition"
	#		}
	#
	#		map "Air temperature fuel correction" {
	#			style = 2
	#			source = "e6k.maps.atfc"
	#		}
	#
	#		map "Air temperature ignition correction" {
	#			style = 2
	#			source = "e6k.maps.atic"
	#		}
	#
	#		map "Coolant temperature fuel correction" {
	#			style = 2
	#			source = "e6k.maps.ctfc"
	#		}
	#
	#		map "Coolant temperature ignition correction" {
	#			style = 2
	#			source = "e6k.maps.ctic"
	#		}
	#	}
	#
	#	gauge wbo2 {
	#		source = "te.wbo2"
	#		width = 800
	#		height = 200
	#		x = 0
	#		y = 600
	#		font = sans
	#		font_size = 10
	#	}
	#}


	page datalogging {
		log_viewer {
			width = 800
			height = 600
			x = 0
			y = 0
		}
	}
}